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:
cd byond
sudo make install
rebooted computer
sudo ./ # modified 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:,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), "", "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] [0xf7be2000, 0x0], 0x236548
[0xf7f6e000, 0xf7f6e410], [0xf7f6e000, 0xf7f6e410] [0xf7be2000, 0x0], 0x236548 0x238a4c, 0x238b38 0x21afb8, 0x21b031 [0xf7be2000, 0x0], 0x21b616 [0xf7be2000, 0x0], 0x2277e1 0x238a4c, 0x238b38 0x21afb8, 0x21b031 [0xf7be2000, 0x0], 0x21b579 [0xf7be2000, 0x0], 0x2277e1 0x238a4c, 0x238b38 0x21afb8, 0x21b031 [0xf7be2000, 0x0], 0x21b579 [0xf7be2000, 0x0], 0x2277e1 0x238a4c, 0x238b38 0x21afb8, 0x21b031 [0xf7be2000, 0x0], 0x21b616 [0xf7be2000, 0x0], 0x2277e1 0x238a4c, 0x238b38 0x21afb8, 0x21b031 0x21c878, 0x21c8fd [0xf7be2000, 0x0], 0x1f7f88 [0xf7be2000, 0x0], 0x1f8cdd 0x1f9d94, 0x1fa035 0x23c190, 0x23c1f1 0x272218, 0x272327 [0xf7be2000, 0x0], 0x2721df 0x2744dc, 0x274a8c
DreamDaemon [0x8048000, 0x0], [0x8048000, 0x8049e77] 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:

edit: updated last line of FFO log.txt, was previously not copied in its entirety.
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.

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.
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:
if(O) if(!O.warp_check(src)) return
if(!src:pre_warp(T,O)) return
else if(istype(src,/mob/NPC)) if(src:town)
if(T.loc != src:town:town_area) return
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(findtext(O.icon_state,"door")) flick("[O.icon_state] open",O)
D = locate() in O.contents
if(conscience.PC) if(src:target == D) src:target = null
flick("[D.icon_state] open",D)

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.

forgot to mention, running FFO in DS in Windows Vista works properly
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.