ID:115340
 
BYOND Version:487
Operating System:FreeBSD
Web Browser:
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.
Core file will be provided directly to Tom & Lummox JR.

BUG: Crashing due to an illegal operation!
proc name: key name (/proc/key_name)
source file: helpers.dm,616
usr: BrotherBear (/mob/new_player)
src: null
call stack:
key name(BrotherBear (/mob/new_player), null, 1)
BrotherBear (/mob/new_player): Logout()
BrotherBear (/mob/new_player): Logout()
Medical Research (/area/medical/research): New()
the floor (52,97,1) (/turf/simulated/floor): sd LumUpdate()
the light fixture (/obj/machinery/light): sd StripLum(/list (/list), the light fixture (/obj/machinery/light))
the light fixture (/obj/machinery/light): sd SetLuminosity(8)
the light fixture (/obj/machinery/light): update()
the light fixture (/obj/machinery/light): seton(1)
the light fixture (/obj/machinery/light): power change()

Backtrace for BYOND 487.1096 on FreeBSD:
Generated at Sat Jul 2 08:52:57 2011

DreamDaemon [0x8048000, 0x804999c], [0x8048000, 0x804adb4]
libc.so.7 0xe8068, 0xe8074 (strcpy)
libbyond.so 0x24ddf0, 0x266080
libbyond.so 0x267fc0, 0x2680af
libbyond.so 0x24ddf0, 0x25d2d2
libbyond.so 0x267fc0, 0x2680af
libbyond.so 0x269e70, 0x26fe65
libbyond.so 0x24ddf0, 0x255413
libbyond.so 0x267fc0, 0x2680af
libbyond.so 0x2680e0, 0x268184
libbyond.so 0x269d60, 0x269e11
libbyond.so 0x1fe400, 0x1fe47c
libbyond.so 0x2809d0, 0x281248
libbyond.so 0x281340, 0x28142c
libbyond.so 0x2bb820, 0x2bbab6
libbyond.so 0x2bc2b0, 0x2bc489
libbyond.so 0x271b10, 0x271b45
libbyond.so 0x27d050, 0x27d20c
libbyond.so 0x2204f0, 0x22052b
libbyond.so 0x214eb0, 0x21539b
libbyond.so 0x215bc0, 0x215c88
libbyond.so 0x241fd0, 0x244bd6
libbyond.so 0x24cd60, 0x24d10d
libbyond.so 0x2680e0, 0x269b0b
libbyond.so 0x24ddf0, 0x25d688
libbyond.so 0x267fc0, 0x2680af
libbyond.so 0x2680e0, 0x268184
libbyond.so 0x2680e0, 0x268640
libbyond.so 0x24ddf0, 0x254ea8
libbyond.so 0x267fc0, 0x2680af
libbyond.so 0x2680e0, 0x268184
libbyond.so 0x2680e0, 0x269334
libbyond.so 0x24ddf0, 0x2552ca
libbyond.so 0x267fc0, 0x2680af
libbyond.so 0x2680e0, 0x268184
libbyond.so 0x2680e0, 0x269334
libbyond.so 0x24ddf0, 0x2552ca
libbyond.so 0x267fc0, 0x2680af
libbyond.so 0x2680e0, 0x268184
libbyond.so 0x2680e0, 0x269334
libbyond.so 0x24ddf0, 0x2552ca
libbyond.so 0x267fc0, 0x2680af
libbyond.so 0x2680e0, 0x268184
libbyond.so 0x2680e0, 0x269334
libbyond.so 0x24ddf0, 0x2552ca
libbyond.so 0x267fc0, 0x2680af
libbyond.so 0x2680e0, 0x268184
libbyond.so 0x2680e0, 0x269334
libbyond.so 0x24ddf0, 0x2552ca
libbyond.so 0x24ddf0, 0x266d14

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


DreamDaemon will now produce a file called 'core' that you can send to the
BYOND developers for more analysis. For instructions, please contact us at
http://www.byond.com/support/
Thanks. What is the context of this crash? Is it happening every time, just the one time, at startup, etc?
It was a one-off crash, no context that I can give you, sorry. Happened after about 24 hours of uptime. I noticed the crash was in strcpy so I figured I'd post the crash.
Just to add to the notes on this, so far we know this is crashing on the following line of code:

text += "[the_key]"


The text var is always a string, and the_key is taken from mob.key and should therefore either be a string or null. It seems unlikely that this could have been corrupted. However, this line also does not execute unless mob.client is not null. Curiously, this is happening in a Logout() call, where the client is usually null already. Even more curiously, this is happening when an area is created, suggesting something in the area's creation is triggering the logout. This may therefore not be a true logout but merely a case of a client being transferred to another mob.
Further note: The strcpy() call is failing even after calls to strlen(), malloc(), and memcpy() that obviously did not, but with basically all the same info. At this time I suspect a hardware issue is involved, but we'll need more data.