ID:806256
 
BYOND Version:493
Operating System:Linux
Web Browser:Chrome 20.0.1132.27
Applies to:Dream Daemon
Status: Unverified

Thus far we've been unable to verify or reproduce this bug. Or, it has been observed but it cannot be triggered with a reliable test case. You can help us out by editing your report or adding a comment with more information.
As of lately I've been having a crashing issue with my server so I decided to run it with the trace option, I'm not sure you guys can make anything of it, but here it is.


BUG: Crashing due to an illegal operation!

Backtrace for BYOND 493.1116 on Linux:
Generated at Sat Jun 9 01:47:55 2012

DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a708]
libbyond.so 0x2b5830, 0x2b584c
[0x530000, 0x530440], [0x530000, 0x530440]
libbyond.so 0x2b5830, 0x2b584c
libbyond.so [0x110000, 0x0], 0x24729a
libbyond.so [0x110000, 0x0], 0x24834b
libbyond.so [0x110000, 0x0], 0x24ad05
libbyond.so 0x24fbd0, 0x24fd50
libbyond.so [0x110000, 0x0], 0x257cfa
libbyond.so 0x31bfe0, 0x31c13c
libbyond.so 0x2ef410, 0x2ef646
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a203]
libc.so.6 0x15dc0, 0x15e9c (__libc_start_main)
DreamDaemon [0x8048000, 0x8049b9c], [0x8048000, 0x8049cd1]
It crashed again with the following trace:


BUG: Failed to fseek() in ClientSocket::SendNextPacket(159,0,0,1,2): Bad file descriptor
BUG: Failed to send 'resources'
BUG: Unexpected file transmission (packet_num = 2 (expected = 1),max=16,pid=4294967295)
BUG: Removing corrupt rsc entry 'Spiderman.dmi'
BUG: Failed to complete download
BUG: Finished erasure with refcount=4 (ref=5:3) DM (:0)
BUG: Failed to create rsc batch
BUG: Finished erasure with refcount=6 (ref=5:22) DM (:0)
BUG: Finished erasure with refcount=11 (ref=5:43) DM (:0)
BUG: Finished erasure with refcount=1 (ref=5:19) DM (:0)
*** glibc detected *** DreamDaemon: corrupted double-linked list: 0x0fb4cee0 ***
======= Backtrace: =========
/lib/libc.so.6[0x5bc3f6]
/lib/libc.so.6[0x5be657]
/lib/libc.so.6(__libc_malloc+0x67)[0x5c07d7]
/usr/local/lib/libbyond.so(_ZN6NetMsg9IncBuflenEm+0x122)[0xe3 b972]
/usr/local/lib/libbyond.so(_ZN6NetMsg10ZipPackageEPhm+0x67)[0 xe3c2e7]
/usr/local/lib/libbyond.so(_ZN12ClientSocket7SendBufEPKcl+0x1 56)[0xe412c6]
/usr/local/lib/libbyond.so(_ZN12ClientSocket10FlushQueueEv+0x 32)[0xe414e2]
/usr/local/lib/libbyond.so(_Z8SendMapsv+0x1a1)[0xda5d71]
/usr/local/lib/libbyond.so[0xdadcfa]
/usr/local/lib/libbyond.so(_ZN7TimeLib11SystemAlarmEv+0x15c)[ 0xe7213c]
/usr/local/lib/libbyond.so(_ZN9SocketLib15WaitForSocketIOElh+ 0x236)[0xe45646]
DreamDaemon[0x804a203]
/lib/libc.so.6(__libc_start_main+0xdc)[0x56be9c]
DreamDaemon(__gxx_personality_v0+0x135)[0x8049cd1]
======= Memory map: ========
00110000-00307000 r-xp 00000000 09:02 8851277 /usr/local/byond/bin/libext.so
00307000-00308000 rwxp 001f6000 09:02 8851277 /usr/local/byond/bin/libext.so
00308000-003e8000 r-xp 00000000 09:02 8069669 /usr/lib/libstdc++.so.6.0.8
003e8000-003ec000 r-xp 000df000 09:02 8069669 /usr/lib/libstdc++.so.6.0.8
003ec000-003ed000 rwxp 000e3000 09:02 8069669 /usr/lib/libstdc++.so.6.0.8
003ed000-003f3000 rwxp 003ed000 00:00 0
003f3000-003fe000 r-xp 00000000 09:02 9404664 /lib/libgcc_s-4.1.2-20080825.so.1
003fe000-003ff000 rwxp 0000a000 09:02 9404664 /lib/libgcc_s-4.1.2-20080825.so.1
003ff000-00403000 r-xp 00000000 09:02 9404452 /lib/libnss_dns-2.5.so
00403000-00404000 r-xp 00003000 09:02 9404452 /lib/libnss_dns-2.5.so
00404000-00405000 rwxp 00004000 09:02 9404452 /lib/libnss_dns-2.5.so
00537000-00552000 r-xp 00000000 09:02 9404607 /lib/ld-2.5.so
00552000-00553000 r-xp 0001a000 09:02 9404607 /lib/ld-2.5.so
00553000-00554000 rwxp 0001b000 09:02 9404607 /lib/ld-2.5.so
00556000-006a8000 r-xp 00000000 09:02 9404608 /lib/libc-2.5.so
006a8000-006a9000 --xp 00152000 09:02 9404608 /lib/libc-2.5.so
006a9000-006ab000 r-xp 00152000 09:02 9404608 /lib/libc-2.5.so
006ab000-006ac000 rwxp 00154000 09:02 9404608 /lib/libc-2.5.so
006ac000-006af000 rwxp 006ac000 00:00 0
006b1000-006d8000 r-xp 00000000 09:02 9404640 /lib/libm-2.5.so
006d8000-006d9000 r-xp 00026000 09:02 9404640 /lib/libm-2.5.so
006d9000-006da000 rwxp 00027000 09:02 9404640 /lib/libm-2.5.so
006dc000-006df000 r-xp 00000000 09:02 9404618 /lib/libdl-2.5.so
006df000-006e0000 r-xp 00002000 09:02 9404618 /lib/libdl-2.5.so
006e0000-006e1000 rwxp 00003000 09:02 9404618 /lib/libdl-2.5.so
0073f000-00740000 r-xp 0073f000 00:00 0 [vdso]
00796000-007a7000 r-xp 00000000 09:02 9405537 /lib/libresolv-2.5.so
007a7000-007a8000 r-xp 00010000 09:02 9405537 /lib/libresolv-2.5.so
007a8000-007a9000 rwxp 00011000 09:02 9405537 /lib/libresolv-2.5.so
007a9000-007ab000 rwxp 007a9000 00:00 0
00b43000-00b4d000 r-xp 00000000 09:02 9404463 /lib/libnss_files-2.5.so
00b4d000-00b4e000 r-xp 00009000 09:02 9404463 /lib/libnss_files-2.5.so
00b4e000-00b4f000 rwxp 0000a000 09:02 9404463 /lib/libnss_files-2.5.so
00b56000-00f42000 r-xp 00000000 09:02 8851279 /usr/local/byond/bin/libbyond.so
00f42000-00f43000 rwxp 003ec000 09:02 8851279 /usr/local/byond/bin/libbyond.so
00f43000-00f5a000 rwxp 00f43000 00:00 0
08048000-0804d000 r-xp 00000000 09:02 8851280 /usr/local/byond/bin/DreamDaemon
0804d000-0804e000 rw-p 00004000 09:02 8851280 /usr/local/byond/bin/DreamDaemon
08d85000-11689000 rw-p 08d85000 00:00 0 [heap]
b799a000-b799b000 rw-p b7b29000 00:00 0
b7b27000-b7b28000 rw-p b7b27000 00:00 0
b7bae000-b7baf000 rw-p b7bae000 00:00 0
b7e00000-b7e21000 rw-p b7e00000 00:00 0
b7e21000-b7f00000 ---p b7e21000 00:00 0
b7fbf000-b7fc4000 rw-p b7fbf000 00:00 0
b7fc5000-b7fe1000 rw-p b7fc5000 00:00 0
b7fe1000-b7fe9000 rw-p b7fe1000 00:00 0
bfe95000-bfef7000 rw-p bff9c000 00:00 0 [stack]
I would really like a response on this.
Sorry about the delay getting back to you on these traces. From what I can see, these crashes are completely separate. The first is a corruption of a data object used to hold some references known to a given client. A crash in this routine makes no sense unless memory has been corrupted. The second crash is in a completely different place, in a routine used to allocate space for sending a message, and the failure being reported is in the bowels of malloc() which again says memory was corrupted.

Unfortunately neither trace points to the actual cause, as is so often the case with memory corruption. Both are related to sending map info to the client, but as this is one of the server's primary duties that may or may not be a significant clue. It would help, I think, to know if you have any unusual cases in your game like objects with ginormous icons or such. Anything remotely map-related that your game does that most others do not would be a helpful point of reference. (My hope is that the flaw lies close to the point of failure, rather than happening some indeterminate amount of time before. If the corruption is happening within the same map sending call that ultimately controls the functions that's crashing, it may be much easier to catch.)

Obviously a test case that crashes on a reliable basis would also be handy, but I understand if that's hard to come by.
I really don't know where the errors are coming from, but my game seems to be crashing again.


BUG: Crashing due to an illegal operation!

Backtrace for BYOND 495.1136 on Linux:
Generated at Sun Jul 1 02:31:23 2012

DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a8ce]
libbyond.so 0x254be0, 0x254f15
[0xff9000, 0xff9440], [0xff9000, 0xff9440]
libbyond.so 0x254be0, 0x254f15
libbyond.so [0x9cc000, 0x0], 0x25cf0a
libbyond.so 0x325200, 0x325377
libbyond.so 0x2f7af0, 0x2f7d5a
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a3ee]
libc.so.6 0x15dc0, 0x15e9c (__libc_start_main)
DreamDaemon [0x8048000, 0x8049b04], [0x8048000, 0x8049ed1]

To help the BYOND developers debug this, please send the above trace as part
of a very detailed bug report: http://www.byond.com/members/?command=view_tracker&tracker=1

Sun Jul 1 03:21:46 2012
World opened on network port 8572.
Welcome BYOND! (4.0 Public Version 495.1136)
The BYOND hub reports that port 8572 is not reachable.
The BYOND hub reports that port 8572 is reachable.
BUG: Finished erasure with refcount=1 (ref=5:2) DM (:0)
BUG: Finished erasure with refcount=1 (ref=5:24) DM (:0)
*** glibc detected *** DreamDaemon: corrupted double-linked list: 0x0e5fe5b8 ***
======= Backtrace: =========
/lib/libc.so.6[0x8923f6]
/lib/libc.so.6[0x894657]
/lib/libc.so.6(__libc_malloc+0x67)[0x8967d7]
/usr/local/lib/libbyond.so(_Z7ValsDupP5Valuemm+0x3f)[0x33de1f]
/usr/local/lib/libbyond.so[0x3758e1]
/usr/local/lib/libbyond.so[0x389be3]
/usr/local/lib/libbyond.so[0x38a0a9]
/usr/local/lib/libbyond.so[0x3a4b75]
/usr/local/lib/libbyond.so[0x38ac2f]
/usr/local/lib/libbyond.so[0x3a5949]
/usr/local/lib/libbyond.so(_Z8TickProcl+0x125)[0x3a5e05]
/usr/local/lib/libbyond.so[0x36cdbc]
/usr/local/lib/libbyond.so(_ZN7TimeLib11SystemAlarmEv+0x177)[ 0x435377]
/usr/local/lib/libbyond.so(_ZN9SocketLib15WaitForSocketIOElh+ 0x26a)[0x407d5a]
DreamDaemon[0x804a3ee]
/lib/libc.so.6(__libc_start_main+0xdc)[0x841e9c]
DreamDaemon(__gxx_personality_v0+0x3cd)[0x8049ed1]
======= Memory map: ========
00110000-00516000 r-xp 00000000 09:02 8851279 /usr/local/byond/bin/libbyond.so
00516000-00518000 rwxp 00405000 09:02 8851279 /usr/local/byond/bin/libbyond.so
00518000-0052f000 rwxp 00518000 00:00 0
0052f000-00532000 r-xp 00000000 09:02 9404618 /lib/libdl-2.5.so
00532000-00533000 r-xp 00002000 09:02 9404618 /lib/libdl-2.5.so
00533000-00534000 rwxp 00003000 09:02 9404618 /lib/libdl-2.5.so
00537000-00552000 r-xp 00000000 09:02 9404607 /lib/ld-2.5.so
00552000-00553000 r-xp 0001a000 09:02 9404607 /lib/ld-2.5.so
00553000-00554000 rwxp 0001b000 09:02 9404607 /lib/ld-2.5.so
00554000-0057b000 r-xp 00000000 09:02 9404640 /lib/libm-2.5.so
0057b000-0057c000 r-xp 00026000 09:02 9404640 /lib/libm-2.5.so
0057c000-0057d000 rwxp 00027000 09:02 9404640 /lib/libm-2.5.so
0057d000-00588000 r-xp 00000000 09:02 9404664 /lib/libgcc_s-4.1.2-20080825.so.1
00588000-00589000 rwxp 0000a000 09:02 9404664 /lib/libgcc_s-4.1.2-20080825.so.1
00589000-00593000 r-xp 00000000 09:02 9404463 /lib/libnss_files-2.5.so
00593000-00594000 r-xp 00009000 09:02 9404463 /lib/libnss_files-2.5.so
00594000-00595000 rwxp 0000a000 09:02 9404463 /lib/libnss_files-2.5.so
00595000-005a6000 r-xp 00000000 09:02 9405537 /lib/libresolv-2.5.so
005a6000-005a7000 r-xp 00010000 09:02 9405537 /lib/libresolv-2.5.so
005a7000-005a8000 rwxp 00011000 09:02 9405537 /lib/libresolv-2.5.so
005a8000-005aa000 rwxp 005a8000 00:00 0
0061c000-0082b000 r-xp 00000000 09:02 8851277 /usr/local/byond/bin/libext.so
0082b000-0082c000 rwxp 0020e000 09:02 8851277 /usr/local/byond/bin/libext.so
0082c000-0097e000 r-xp 00000000 09:02 9404608 /lib/libc-2.5.so
0097e000-0097f000 --xp 00152000 09:02 9404608 /lib/libc-2.5.so
0097f000-00981000 r-xp 00152000 09:02 9404608 /lib/libc-2.5.so
00981000-00982000 rwxp 00154000 09:02 9404608 /lib/libc-2.5.so
00982000-00985000 rwxp 00982000 00:00 0
00bd2000-00bd3000 r-xp 00bd2000 00:00 0 [vdso]
00cda000-00cde000 r-xp 00000000 09:02 9404452 /lib/libnss_dns-2.5.so
00cde000-00cdf000 r-xp 00003000 09:02 9404452 /lib/libnss_dns-2.5.so
00cdf000-00ce0000 rwxp 00004000 09:02 9404452 /lib/libnss_dns-2.5.so
00ced000-00dcd000 r-xp 00000000 09:02 8069669 /usr/lib/libstdc++.so.6.0.8
00dcd000-00dd1000 r-xp 000df000 09:02 8069669 /usr/lib/libstdc++.so.6.0.8
00dd1000-00dd2000 rwxp 000e3000 09:02 8069669 /usr/lib/libstdc++.so.6.0.8
00dd2000-00dd8000 rwxp 00dd2000 00:00 0
08048000-0804d000 r-xp 00000000 09:02 8851280 /usr/local/byond/bin/DreamDaemon
0804d000-0804e000 rw-p 00005000 09:02 8851280 /usr/local/byond/bin/DreamDaemon
09881000-0eca9000 rw-p 09881000 00:00 0 [heap]
b7500000-b7521000 rw-p b7500000 00:00 0
b7521000-b7600000 ---p b7521000 00:00 0
b7652000-b7653000 rw-p b7713000 00:00 0
b7710000-b7713000 rw-p b7710000 00:00 0
b788e000-b7893000 rw-p b788e000 00:00 0
b794f000-b7f3e000 rw-p b794f000 00:00 0
b7f3e000-b7f46000 rw-p b7f3e000 00:00 0
bfc3c000-bfcbc000 rw-p bff7e000 00:00 0 [stack]

I would appreciate it if you could help me find the cause.
This crash trace says it's happening in the routine that sends the HUD to the client. It's trying to read from a pointer that isn't valid, which says the linked list controlling the client's HUD (on the server side) is corrupted. This again points to some kind of memory corruption, which is impossible to pinpoint based on this info.

Like I said, anything your game does map-related that most others don't would be really helpful to know as it would at least point out a place to look. It might not fully be a map issue of course, as it could be that the client structure itself is being corrupted and the map routines are merely the ones hitting the problem. It could still be something entirely different, but since map routines seem to be a common place for the crash it seems likely to me that something in one of them is the trigger.
It has a HUD for health, buttons windows and such, the damage numbers from punches also appear there but I haven't been able to figure out what triggers it.EDIT I also use some transparency effect for trees and such. If you join my server http://www.byond.com/games/Falacy/HeroesUnited2 you will see it when you stand under a tree.
I'm not sure what you mean by transparency effect or how it's implemented; that would help to know. This being Falacy's game though I doubt you have access to the source, which hinders me in figuring out how the server would differ from other games.

I still wouldn't entirely rule out simply running out of memory, especially in a game known to be very popular, but there would probably be other signs of that.
In response to Lummox JR
Infact, Falacy released Hu2 as an open source game a while back, when everyone had forums. He's been updating it from then because the OS he released was version 76, this is 105.
I can give you a copy of the source if that would help. EDIT I'm afraid I'll have to write a program to maintain the server for now, these crashes have caused a drop in my player-base. Not cool.
The source might help, or it might not; I just think it'd be good to know what sort of things are in use. Sadly the fact that it's someone else's source hurts my chances of finding anything though, because I don't think you'd be as familiar with the full set of features involved. (And experience has taught me that trying to scan someone else's code without guidance is unfruitful unless I know roughly what to look for.) The problem with these kinds of games is that they're very complex, memory-intensive to host, and often only show problems under player load.

If other servers are not having this problem then I'd have to say the issue would be related either to a local savefile on your server, or to a configuration/limitation issue like running out of memory. Does the issue crop up during even times of low usage? If it always happens with a certain number of players, the player limit solution employed by many servers would be the best option.

Obviously even if memory is running out, it's not being handled as gracefully as it should. (In fairness, running out of memory is often a condition that's hard to recover from anyway.) One way or another, something is corrupting what's left and that's a problem. The hard part is that the crash traces don't tell me where the corruption happened, only that it did. In the past users have tried using Microsoft's Application Verifier (part of their debugging suite) and turned on heap checking, but this obviously won't apply on Linux and I have no answers there short of using a tool like Valgrind. It is likely that with heap checking you will not be able to run under normal load, but under partial load you may still be able to see the corruption as it happens. I can't advise you on the use of this tool as I'm by no means a Linux guru, but if you do use Valgrind or something like it to look for heap corruption, then there's a much better chance of triggering a fault at the actual point of failure and that would be the smoking gun I need.
My server has about 32GB of memory so I doubt it's running out. But I'll give Valgrind a try.
The program is 32-bit and can only access 2 or 4 GB (I'm not sure which). All 32 GB will cover is ensuring that you have plenty of memory for other applications.
In that case I pay way too much :P. I'll try to reproduce the crash on a Windows machine to see if that gives a more helpful trace.
It essentially depends on the calls BYOND makes, and the OS and architecture in question.

For Windows, your upper limit will always be 4 GB as they operate a flat memory model, so your pointer types have no sense of segmentation in them. But essentially it goes like so, for a x86 user-space application (BYOND):

Windows systems on a x86 architecture:
2 GB, or 3 GB with /3GB compile option from MSVC.

Windows systems on an x64 architecture:
2 GB, or 4 GB with /3GB compile option from MSVC.

To avoid all your x86 user-space applications (so say ... multiple BYOND worlds) being limited to sharing the lowest 4 GB of kernel address space, you require PAE and a PAE aware Windows OS, which would be anything from Windows XP up I believe, and suitable CPU support (which ... you probably have until it's a Pentium 3 or some such).

Linux memory models happen to operate the 4 GB principal regardless, and come with PAE detection as of ... forever and a day. Linux also offers alternative memory models to the flat model, so (if home brewed kernel / Gentoo) can permit a x86 user-space application to address I think it's up to 64 GB of memory with a segmented addressing scheme, on x86 or x86_64 architectures (at cost to addressing speed in x86_64's case). I don't know of a distribution that builds this as standard for their installs due to the performance overhead.
I really can't figure out how to use Valgrind so I'll resort to writing a server monitor for now.
Lummox JR changed status to 'Unverified'
The error has been away for some time but it came back, I'm not sure if you can give me any information on these but it'd be nice to know what causes it, or rather what's related to it.
BUG: Finished erasure with refcount=1 (ref=5:10) DM (:0)
BUG: Finished erasure with refcount=9 (ref=5:3) DM (:0)
BUG: Finished erasure with refcount=1 (ref=5:33) DM (:0)
BUG: Removing corrupt rsc entry 'Android 27.dmi'
BUG: Finished erasure with refcount=3 (ref=5:37) DM (:0)
BUG: Finished erasure with refcount=7 (ref=5:2) DM (:0)
BUG: Finished erasure with refcount=2 (ref=5:13) DM (:0)
BUG: Finished erasure with refcount=1 (ref=5:42) DM (:0)
BUG: Doubly premature return value!
BUG: Finished erasure with refcount=8 (ref=5:48) DM (:0)
BUG: Finished erasure with refcount=6 (ref=5:16) DM (:0)
BUG: Finished erasure with refcount=3 (ref=5:14) DM (:0)
BUG: Finished erasure with refcount=5 (ref=5:49) DM (:0)
BUG: Finished erasure with refcount=1 (ref=5:2) DM (:0)
BUG: Finished erasure with refcount=1 (ref=5:6) DM (:0)
BUG: Finished erasure with refcount=1 (ref=5:51) DM (:0)
BUG: Finished erasure with refcount=9 (ref=5:9) DM (:0)
BUG: Finished erasure with refcount=2 (ref=5:50) DM (:0)
BUG: Finished erasure with refcount=2 (ref=5:57) DM (:0)
BUG: Finished erasure with refcount=1 (ref=5:33) DM (:0)
BUG: Finished erasure with refcount=2 (ref=5:49) DM (:0)
BUG: Finished erasure with refcount=1 (ref=5:30) DM (:0)
BUG: Finished erasure with refcount=1 (ref=5:3) DM (:0)
BUG: Finished erasure with refcount=4 (ref=5:40) DM (:0)
BUG: Finished erasure with refcount=5 (ref=5:46) DM (:0)
BUG: Finished erasure with refcount=1 (ref=5:2) DM (:0)
BUG: Finished erasure with refcount=1 (ref=5:24) DM (:0)
BUG: Finished erasure with refcount=2 (ref=5:10) DM (:0)
BUG: Finished erasure with refcount=2 (ref=5:47) DM (:0)
BUG: Finished erasure with refcount=3 (ref=5:37) DM (:0)
BUG: Removing corrupt rsc entry 'gymleadericon.dmi'
BUG: Removing corrupt rsc entry 'gymleadericon.dmi'
BUG: Removing corrupt rsc entry 'Chili.dmi'
BUG: Removing corrupt rsc entry 'Shen.dmi'
BUG: Removing corrupt rsc entry 'Wargreymon.dmi'
BUG: Removing corrupt rsc entry 'gymleadericon.dmi'
BUG: Removing corrupt rsc entry 'Team Plasma Leader N.dmi'
BUG: Finished erasure with refcount=2 (ref=5:3) DM (:0)
BUG: Finished erasure with refcount=1 (ref=5:62) DM (:0)
BUG: Finished erasure with refcount=11 (ref=5:27) DM (:0)
BUG: Removing corrupt rsc entry 'Android 27.dmi'
BUG: Finished erasure with refcount=2 (ref=5:39) DM (:0)
BUG: Finished erasure with refcount=1 (ref=5:3) DM (:0)
BUG: Finished erasure with refcount=3 (ref=5:55) DM (:0)
BUG: Finished erasure with refcount=2 (ref=5:47) DM (:0)
BUG: Finished erasure with refcount=2 (ref=5:19) DM (:0)
BUG: Finished erasure with refcount=5 (ref=5:28) DM (:0)
BUG: Finished erasure with refcount=1 (ref=5:38) DM (:0)
BUG: Finished erasure with refcount=7 (ref=5:59) DM (:0)
BUG: Finished erasure with refcount=2 (ref=5:30) DM (:0)
BUG: Finished erasure with refcount=2 (ref=5:50) DM (:0)
BUG: Finished erasure with refcount=9 (ref=5:24) DM (:0)
BUG: Finished erasure with refcount=1 (ref=5:41) DM (:0)
BUG: Finished erasure with refcount=1 (ref=5:42) DM (:0)
BUG: Finished erasure with refcount=1 (ref=5:37) DM (:0)
BUG: Finished erasure with refcount=5 (ref=5:21) DM (:0)
BUG: Finished erasure with refcount=26 (ref=5:66) DM (:0)
BUG: Finished erasure with refcount=2 (ref=5:6) DM (:0)
BUG: Finished erasure with refcount=1 (ref=5:41) DM (:0)
BUG: Doubly premature return value!
BUG: Finished erasure with refcount=6 (ref=5:54) DM (:0)
BUG: Finished erasure with refcount=1 (ref=5:43) DM (:0)
BUG: Removing corrupt rsc entry 'SS3 Vegeta.dmi'
BUG: Removing corrupt rsc entry 'SS3 Vegeta.dmi'
BUG: Removing corrupt rsc entry 'SS3 Vegeta.dmi'
BUG: Finished erasure with refcount=5 (ref=5:34) DM (:0)
BUG: Finished erasure with refcount=6 (ref=5:44) DM (:0)
BUG: Finished erasure with refcount=2 (ref=5:61) DM (:0)
BUG: Sequence number 35DC expected but 42 received
*** glibc detected *** DreamDaemon: malloc(): smallbin double linked list corrupted: 0x0d01d380 ***
======= Backtrace: =========
/lib/libc.so.6[0x40e5b6]
/lib/libc.so.6(__libc_malloc+0x67)[0x40f7d7]
/lib/libc.so.6(__strdup+0x30)[0x4139c0]
/usr/local/lib/libbyond.so(_Z18ExpandFileNameListPKcPPPct+0x14c)[0x8658ec]
/usr/local/lib/libbyond.so(_Z15CorrectFileCasePKc+0x62)[0x8582c2]
/usr/local/lib/libbyond.so(_Z15CorrectPathCasePKci+0x31)[0x858421]
/usr/local/lib/libbyond.so(_Z17GetUniqueFileNamePKc+0x36)[0x8655d6]
/usr/local/lib/libbyond.so(_Z21DeleteSavefilesInPathPKc+0x14)[0x75b074]
/usr/local/lib/libbyond.so[0x7e354e]
/usr/local/lib/libbyond.so(_Z15ExecProc_Attach5ValuehthS_PS_mPFvS_PvES1_+0x10d)[0x7eaf6d]
/usr/local/lib/libbyond.so(_Z29CallByNameWithCallback_Attach5ValuehmS_PS_mPFvS_PvES1_+0xb2)[0x7eb072]
/usr/local/lib/libbyond.so[0x7ec3dd]
/usr/local/lib/libbyond.so[0x7dcf37]
/usr/local/lib/libbyond.so(_Z15ExecProc_Attach5ValuehthS_PS_mPFvS_PvES1_+0x10d)[0x7eaf6d]
/usr/local/lib/libbyond.so(_Z29CallByNameWithCallback_Attach5ValuehmS_PS_mPFvS_PvES1_+0xb2)[0x7eb072]
/usr/local/lib/libbyond.so(_Z22CallByNameWithCallback5ValuehmS_PS_mPFvS_PvES1_+0xcc)[0x7ed30c]
/usr/local/lib/libbyond.so(_Z9ClearLinkt+0xf6)[0x8059b6]
/usr/local/lib/libbyond.so(_Z14DeallocateLinkt+0xf6)[0x806346]
/usr/local/lib/libbyond.so(_Z17ServerSendQuitMsgttm+0x61)[0x79ddb1]
/usr/local/lib/libbyond.so(_Z9CheckBanst+0xec)[0x7abc9c]
/usr/local/lib/libbyond.so[0x7acff4]
/usr/local/lib/libbyond.so(_Z15ServerHandleMsgR6NetMsgt+0xa3)[0x7aed93]
/usr/local/lib/libbyond.so(_ZN14ServerSideLink9HandleMsgEP6NetMsg+0x99)[0x7f93f9]
/usr/local/lib/libbyond.so(_ZN12ClientSocket7ReadMsgEv+0x2b3)[0x849143]
/usr/local/lib/libbyond.so[0x848d48]
/usr/local/lib/libbyond.so(_ZN9SocketLib15WaitForSocketIOElh+0x6df)[0x84c1cf]
DreamDaemon[0x804a3ee]
/lib/libc.so.6(__libc_start_main+0xdc)[0x3bae9c]
DreamDaemon(__gxx_personality_v0+0x3cd)[0x8049ed1]
======= Memory map: ========
00110000-001f0000 r-xp 00000000 09:02 8069669 /usr/lib/libstdc++.so.6.0.8
001f0000-001f4000 r-xp 000df000 09:02 8069669 /usr/lib/libstdc++.so.6.0.8
001f4000-001f5000 rwxp 000e3000 09:02 8069669 /usr/lib/libstdc++.so.6.0.8
001f5000-001fb000 rwxp 001f5000 00:00 0
001fb000-00222000 r-xp 00000000 09:02 9404640 /lib/libm-2.5.so
00222000-00223000 r-xp 00026000 09:02 9404640 /lib/libm-2.5.so
00223000-00224000 rwxp 00027000 09:02 9404640 /lib/libm-2.5.so
00224000-00227000 r-xp 00000000 09:02 9404618 /lib/libdl-2.5.so
00227000-00228000 r-xp 00002000 09:02 9404618 /lib/libdl-2.5.so
00228000-00229000 rwxp 00003000 09:02 9404618 /lib/libdl-2.5.so
00229000-00233000 r-xp 00000000 09:02 9404463 /lib/libnss_files-2.5.so
00233000-00234000 r-xp 00009000 09:02 9404463 /lib/libnss_files-2.5.so
00234000-00235000 rwxp 0000a000 09:02 9404463 /lib/libnss_files-2.5.so
00235000-00239000 r-xp 00000000 09:02 9404452 /lib/libnss_dns-2.5.so
00239000-0023a000 r-xp 00003000 09:02 9404452 /lib/libnss_dns-2.5.so
0023a000-0023b000 rwxp 00004000 09:02 9404452 /lib/libnss_dns-2.5.so
0023b000-0024c000 r-xp 00000000 09:02 9405537 /lib/libresolv-2.5.so
0024c000-0024d000 r-xp 00010000 09:02 9405537 /lib/libresolv-2.5.so
0024d000-0024e000 rwxp 00011000 09:02 9405537 /lib/libresolv-2.5.so
0024e000-00250000 rwxp 0024e000 00:00 0
002c2000-002c3000 r-xp 002c2000 00:00 0 [vdso]
00399000-003a4000 r-xp 00000000 09:02 9404664 /lib/libgcc_s-4.1.2-20080825.so.1
003a4000-003a5000 rwxp 0000a000 09:02 9404664 /lib/libgcc_s-4.1.2-20080825.so.1
003a5000-004f7000 r-xp 00000000 09:02 9404608 /lib/libc-2.5.so
004f7000-004f8000 --xp 00152000 09:02 9404608 /lib/libc-2.5.so
004f8000-004fa000 r-xp 00152000 09:02 9404608 /lib/libc-2.5.so
004fa000-004fb000 rwxp 00154000 09:02 9404608 /lib/libc-2.5.so
004fb000-004fe000 rwxp 004fb000 00:00 0
00537000-00552000 r-xp 00000000 09:02 9404607 /lib/ld-2.5.so
00552000-00553000 r-xp 0001a000 09:02 9404607 /lib/ld-2.5.so
00553000-00554000 rwxp 0001b000 09:02 9404607 /lib/ld-2.5.so
00554000-0095a000 r-xp 00000000 09:02 8851279 /usr/local/byond/bin/libbyond.so
0095a000-0095c000 rwxp 00405000 09:02 8851279 /usr/local/byond/bin/libbyond.so
0095c000-00973000 rwxp 0095c000 00:00 0
00dcc000-00fdb000 r-xp 00000000 09:02 8851277 /usr/local/byond/bin/libext.so
00fdb000-00fdc000 rwxp 0020e000 09:02 8851277 /usr/local/byond/bin/libext.so
08048000-0804d000 r-xp 00000000 09:02 8851280 /usr/local/byond/bin/DreamDaemon
0804d000-0804e000 rw-p 00005000 09:02 8851280 /usr/local/byond/bin/DreamDaemon
08d01000-0fea9000 rw-p 08d01000 00:00 0 [heap]
b7400000-b7421000 rw-p b7400000 00:00 0
b7421000-b7500000 ---p b7421000 00:00 0
b756c000-b756d000 rw-p b7863000 00:00 0
b7765000-b7766000 rw-p b7765000 00:00 0
b7862000-b7863000 rw-p b7862000 00:00 0
b7951000-b7953000 rw-p b7951000 00:00 0
b7954000-b7958000 rw-p b7954000 00:00 0
b7959000-b7f4e000 rw-p b7959000 00:00 0
b7f4e000-b7f55000 rw-p b7f4e000 00:00 0
bfd44000-bfdd8000 rw-p bff6a000 00:00 0 [stack]
Sadly that trace has the same issue as the others; it's clear that something has overstepped its bounds in memory, but not where. The crash is happening in the aftermath.

I'd like to know if there's a reliable test case for that refcount error and the doubly premature return value, though. That's been around a long time. I can't tell whether it's related to your issue or not; I suspect it isn't, but there's no way to know till I know why it happens.
I can send you a copy of the source if that would help. Also, why does trace.txt say ../libdung/server/stick.cpp:132? I hope you understand that the issue is quite annoying, I honestly hate to bother you with more stuff and I have no doubt you already have your hands full.
Page: 1 2