BYOND BUG, program crash at line with flick(icon_state,) in Bug Reports

ID:78558
 
Aug 6 2009, 11:19 am (Edited on Aug 6 2009, 11:27 am)
Resolved
Fixed in 449
BYOND Version:448
Operating System:Linux
Web Browser:
Status: Resolved (449)
This issue has been resolved.
Duplicates:id:78648, id:78594
Descriptive Problem Summary:

performed "make install" of 448.1029 (fresh from byond) on FFO server
booted FFO using standard script
FFO crashes soon after booting
a single bug reported in error log
nohup.out shows bug trace

Numbered Steps to Reproduce Problem:
unzip 448.1029_byond_linux.zip
cd byond
sudo make install
rebooted computer
sudo ./BYOND.sh # modified FFO.sh startup script
FFO launched by line: exec nohup DreamDaemon FFO/FFO.dmb 2442 -public &
game proceeded through boot process as expected (~4 minutes)
attempted to log in when CPU usage dropped as seen in "top"
successfully made it through game's login process
game crashed the moment I spawned on the map
FFO log file reports crash but doesn't say what the error was
nohup.out reports BYOND bug trace

DreamDaemon -version reports proper version

FFO log.txt reports:
proc name: G warp (/mob/G_warp)
  source file: Turfs.dm,60
  usr: Gakumerasara (/mob/Login)
  src:  (/mob/PC/Red_Mage)
  call stack:
 (/mob/PC/Red_Mage): G warp( (124,141,5) (/turf/warp/NB/Storage_W_O), null)
 (/mob/PC/Red_Mage): spawn location()
 (/mob/PC/Red_Mage): custom login(null)
Gakumerasara (/mob/Login): load()
Gakumerasara (/client): MouseDown( (/obj/popup/background/load),  (4,16,1) (/turf/title), "mapwindow.map", "icon-x=29;icon-y=20;left=1;scr...")

note the lack of a reported error

examining this line in code reveals the following line:
if(findtext(T.icon_state,"door")) flick("[T.icon_state] open",T)
where T is a turf being warped to

nohup.out reports:
Thu Aug  6 14:05:01 2009
Auto-safety mode: safe (working directory access).
World opened on network port 2442.
Welcome BYOND! (4.0 Public Version 448.1029)
The BYOND hub reports that port 2442 is reachable.
BUG: Crashing due to an illegal operation!

Backtrace for BYOND 448.1029 on Linux:
Generated at Thu Aug  6 14:10:45 2009

DreamDaemon [0x8048000, 0x0], [0x8048000, 0x804a8f8]
libbyond.so [0xf7be2000, 0x0], 0x236548
 [0xf7f6e000, 0xf7f6e410], [0xf7f6e000, 0xf7f6e410]
libbyond.so [0xf7be2000, 0x0], 0x236548
libbyond.so 0x238a4c, 0x238b38
libbyond.so 0x21afb8, 0x21b031
libbyond.so [0xf7be2000, 0x0], 0x21b616
libbyond.so [0xf7be2000, 0x0], 0x2277e1
libbyond.so 0x238a4c, 0x238b38
libbyond.so 0x21afb8, 0x21b031
libbyond.so [0xf7be2000, 0x0], 0x21b579
libbyond.so [0xf7be2000, 0x0], 0x2277e1
libbyond.so 0x238a4c, 0x238b38
libbyond.so 0x21afb8, 0x21b031
libbyond.so [0xf7be2000, 0x0], 0x21b579
libbyond.so [0xf7be2000, 0x0], 0x2277e1         
libbyond.so 0x238a4c, 0x238b38
libbyond.so 0x21afb8, 0x21b031
libbyond.so [0xf7be2000, 0x0], 0x21b616
libbyond.so [0xf7be2000, 0x0], 0x2277e1
libbyond.so 0x238a4c, 0x238b38
libbyond.so 0x21afb8, 0x21b031
libbyond.so 0x21c878, 0x21c8fd
libbyond.so [0xf7be2000, 0x0], 0x1f7f88
libbyond.so [0xf7be2000, 0x0], 0x1f8cdd
libbyond.so 0x1f9d94, 0x1fa035
libbyond.so 0x23c190, 0x23c1f1
libbyond.so 0x272218, 0x272327
libbyond.so [0xf7be2000, 0x0], 0x2721df
libbyond.so 0x2744dc, 0x274a8c
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x8049e77]
libc.so.6 0x16690, 0x16775 (__libc_start_main)
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x8049b81]

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


edit: updated last line of FFO log.txt, was previously not copied in its entirety.
#1 Aug 6 2009, 11:31 am (Edited on Aug 6 2009, 11:37 am)
It's possible the flick itself isn't the problem, because a crash could have happened before the log was fully flushed to the file system.

It'd help to see what the runtime error text was, not just the stack trace for it, and the rest of the code in that proc.

[edit]
I did find one minor nit in flick() that could, under some circumstances, cause some kind of crash. It's possible that's the cause here.
#2 Aug 6 2009, 11:42 am
The log I posted above is everything logged in FFO log.txt
That's why I thought it was odd that it doesn't show what the cause is.

The rest of the code in the proc is:
    G_warp(turf/warp/T,turf/warp/O)
        if(loc)
            if(O) if(!O.warp_check(src)) return
            if(conscience.PC)
                if(!src:pre_warp(T,O)) return
                remove_darkness_overlays()
            else if(istype(src,/mob/NPC)) if(src:town)
                if(T.loc != src:town:town_area) return
            remove_illumination()
        if(findtext(T.icon_state,"door")) flick("[T.icon_state] open",T) // line 60
        var/obj/Door/D = locate() in T.contents
        if(D) flick("[D.icon_state] open",D)
        if(O)
            if(findtext(O.icon_state,"door")) flick("[O.icon_state] open",O)
            D = locate() in O.contents
            if(D)
                if(conscience.PC) if(src:target == D) src:target = null
                flick("[D.icon_state] open",D)
        if(light_radius)
            T.illuminate(brightness,light_radius)
        ..()
        if(conscience.PC)
            add_darkness_overlays()
            src:post_warp(T,O)


As I recall, loc is null at this point, so the whole first part of the proc should be ignored.
I could try inserting a "return" at various places to see which line is causing the crash.

edit:
forgot to mention, running FFO in DS in Windows Vista works properly
#3 Aug 6 2009, 11:58 am
I confirmed that I was able to reproduce a crash in DD under the right circumstances, even running in Windows. The fix I put in place will remedy the problem.