double free in 3.2?

[azundris]

Hi!

I pulled 3.2 from git (18790b9) and built it on openSUSE Linux 13.2 (x86_64). I imported my 3.0 db. MUSH comes up and serves connections etc., but I'm seeing a lot of crashes of the form,

*** Error in `./bin/netmush': double free or corruption (fasttop): 0x0000000000e
46170 ***
#0 0x00007f170d1c6187 in raise () from /lib64/libc.so.6
#1 0x00007f170d1c7538 in abort () from /lib64/libc.so.6
#2 0x00007f170d203844 in __libc_message () from /lib64/libc.so.6
#3 0x00007f170d2090ae in malloc_printerr () from /lib64/libc.so.6
#4 0x00007f170d209db6 in _int_free () from /lib64/libc.so.6
#5 0x0000000000520bc4 in objfree (o=0xdff770) at udb_obj.c:213
#6 0x00000000005213cb in get_free_objpipe (obj=1100) at udb_obj.c:420
#7 0x0000000000521573 in pipe_get_attrib (anum=64, obj=1100) at udb_obj.c:461
#8 0x000000000051ebf5 in cache_get (key=..., type=1) at udb_ocache.c:501
#9 0x00000000004382d2 in atr_get_raw (thing=1100, atr=64) at db.c:2007
#10 0x00000000004384c6 in atr_pget_str (s=0xe2c5d0 "", thing=1100, atr=64,

owner=0x7fff109521b0, flags=0x7fff109521bc, alen=0x7fff109521b8)
at db.c:2069

#11 0x000000000043884b in atr_pget (thing=1100, atr=64, owner=0x7fff109521b0,

flags=0x7fff109521bc, alen=0x7fff109521b8) at db.c:2112

#12 0x000000000041a0a6 in process_command (player=72, cause=72, interactive=1,

command=0xe515f8 "ooc meow", args=0x0, nargs=0) at command.c:1084

#13 0x00000000004cf249 in do_command (d=0xdee8e0, command=0xe515f8 "ooc meow",

first=1) at netcommon.c:1789

#14 0x00000000004cf7d9 in process_commands () at netcommon.c:1920
#15 0x000000000051b520 in shovechars (port=7000) at bsd.c:334
#16 0x00000000004a8666 in main (argc=17, argv=0x7fff10952758) at game.c:2297

Always in get_free_objpipe, as far as I've seen.
Same behavior when testing in a VM (on different underlying hardware, and with a Fedora guest; still x86_64 though).

Have imported via flat-file from tm3.0; later tried Reconstruct, @dbck, flatfile from 3.2 -> 3.2, pretty much anything I could think of. Problem persists.

"A lot" in this context: "at least one crash a day now that not much is happening; easily every ten minutes during heavy grid building."

Please advise:

• is there anything else short of a complete @decompile/replay cycle I can do to give my db some love? But then again, should anything that completes as a valid flat import be able to crash the cache?
• Am I using the recommended version of the server? I had a cursory look at 3.3, but got a little scared when I saw that scripts and command line syntax had changed -- plus, of course, the designation as "alpha". (FWIW, I managed to crash that as well, but only tested on 3.3 very briefly.)

I'm not sure how busy y'all are with other things these days; feel free to tell me to go away, send further info, etc., depending.

thank you very kindly for reading this far; any advice would be welcome.
-A-

[azundris]

Meow? 🐱

[catsafae]

This has been happening to us too, on TinyMUSH 3.2. I don't have all the technical details, bit the error is the same. A few things, though:

• We're doing very light building, and it has been happening one-three times a day.
• It seemed to be happening about the same time each day, though today it didn't.
• It seems only to happen in afternoon and evening.
• Up until today the crash has been sudden and clean.
• Just now it hung the MUSH -- we got the message in TinyFugue that it was connected, but never got the login screen.
• Every time it has happened, someone has been doing something (other than traversing) with exits.