My son just noticed this, and it happens on both of our computers. When you try to start a game of Strife (just a normal SP game), we get dumped to the console with the follwing message:
Zdoom doesn't show the problem, nor does official GZdoom.
I get no crashlog on my machine but, when he quits, my son does on the machine that he is using. Probably of little use seeing as how it's my compile, but here you go.
Posted: Fri Aug 01, 2008 23:43
by Graf Zahl
Works for me. Can you post the startup log?
Posted: Sat Aug 02, 2008 21:39
by Agent ME
Are you using the latest version of strife1.wad? I know there were a few versions of strife, but I can't remember if the wad changed at all between versions.
EDIT: Just tested in r146 in linux - I get the same problem.
Here's the crash in gdb, and a backtrace: I couldn't exactly figure out how to log gdb to a file and the terminal at the same time, so in one terminal I did "gdb ./gzdoomd > crash.txt" and in another terminal I did "tail -f crash.txt" so I could see the commands I typed. Is there a better way? EDIT: "set logging on <file>" does the trick in gdb.
Weird thing, figured it might be useful - in src/v_text.cpp, I commented lines 244-246 to see if that would stop the crash - it still crashed, but the backtrace was different this time.
[New Thread 0x42554950 (LWP 24935)]
[New Thread 0x408b4950 (LWP 24936)]
[Thread 0x41d53950 (LWP 24792) exited]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f51e5fb87c0 (LWP 24791)]
0x00007f51ea5c9bcb in free () from /lib/libc.so.6
#0 0x00007f51ea5c9bcb in free () from /lib/libc.so.6
#1 0x00000000005ed402 in ~FBehavior (this=0x1dbeef0) at /home/chris/Desktop/gzdoom_svn/src/trunk/src/p_acs.cpp:1118
#2 0x00000000005ed5c5 in FBehavior::StaticUnloadModules () at /home/chris/Desktop/gzdoom_svn/src/trunk/src/p_acs.cpp:603
#3 0x0000000000650266 in P_FreeLevelData () at /home/chris/Desktop/gzdoom_svn/src/trunk/src/p_setup.cpp:3089
#4 0x000000000056c46d in C_FullConsole () at /home/chris/Desktop/gzdoom_svn/src/trunk/src/c_console.cpp:1315
#5 0x00000000005ae6ee in G_Ticker () at /home/chris/Desktop/gzdoom_svn/src/trunk/src/g_game.cpp:922
#6 0x000000000058f6b0 in TryRunTics () at /home/chris/Desktop/gzdoom_svn/src/trunk/src/d_net.cpp:1845
#7 0x000000000058814b in D_DoomLoop () at /home/chris/Desktop/gzdoom_svn/src/trunk/src/d_main.cpp:808
#8 0x00000000005894af in D_DoomMain () at /home/chris/Desktop/gzdoom_svn/src/trunk/src/d_main.cpp:2542
#9 0x0000000000555c90 in main (argc=1, argv=0x7ffff666b668) at /home/chris/Desktop/gzdoom_svn/src/trunk/src/sdl/i_main.cpp:269
The program is running. Quit anyway (and detach it)? (y or n) Detaching from program: /home/chris/Desktop/gzdoom_svn/gzdoomd, process 24791
Posted: Tue Aug 05, 2008 9:35
by Graf Zahl
The crash is just a consequence of some lump not being present which then is handled improperly. Unfortunately, unless I can reproduce the error message in the debugger so I can see which lump causes this I can't fix it.
Can you set a breakpoint at the code that prints the W_LumpLength message and then see what the program is doing there?
Posted: Tue Aug 05, 2008 16:26
by Nash
I get the same error as Enjay in my home-compiled GZDoom r148.
Posted: Tue Aug 05, 2008 17:16
by Graf Zahl
That information doesn't help me unless somebody tells me which lump causes the problem. It doesn't happen to me.
Posted: Thu Aug 07, 2008 0:01
by Agent ME
I set a breakpoint on FWadCollection::LumpLength if lump==-1, and did a backtrace soon as it was paused there:
Breakpoint 1 at 0x6df53f: file /home/chris/Desktop/gzdoom_svn/src/trunk/src/w_wad.cpp, line 997.
Starting program: /home/chris/Desktop/gzdoom_svn/gzdoomd
[Thread debugging using libthread_db enabled]
[New Thread 0x7f912fd027c0 (LWP 2414)]
[New Thread 0x4239b950 (LWP 2420)]
[New Thread 0x40960950 (LWP 2425)]
[New Thread 0x42b9c950 (LWP 2426)]
[Thread 0x4239b950 (LWP 2420) exited]
[Switching to Thread 0x7f912fd027c0 (LWP 2414)]
Breakpoint 1, FWadCollection::LumpLength (this=0xcf34a0, lump=-1)
at /home/chris/Desktop/gzdoom_svn/src/trunk/src/w_wad.cpp:997
997 if ((size_t)lump >= NumLumps)
#0 FWadCollection::LumpLength (this=0xcf34a0, lump=-1)
at /home/chris/Desktop/gzdoom_svn/src/trunk/src/w_wad.cpp:997
#1 0x00000000005ef289 in FBehavior (this=0x1e40480, lumpnum=-1, fr=0x0, len=0)
at /home/chris/Desktop/gzdoom_svn/src/trunk/src/p_acs.cpp:770
#2 0x00000000005f044f in FBehavior::StaticLoadModule (lumpnum=-1, fr=0x0,
len=0) at /home/chris/Desktop/gzdoom_svn/src/trunk/src/p_acs.cpp:584
#3 0x00000000005f18a7 in FBehavior::StaticLoadDefaultModules ()
at /home/chris/Desktop/gzdoom_svn/src/trunk/src/p_acs.cpp:550
#4 0x00000000006588c6 in P_SetupLevel (lumpname=0xc4c810 "MAP02", position=0)
at /home/chris/Desktop/gzdoom_svn/src/trunk/src/p_setup.cpp:3340
#5 0x00000000005b5f47 in G_DoLoadLevel (position=0, autosave=false)
at /home/chris/Desktop/gzdoom_svn/src/trunk/src/g_level.cpp:2241
#6 0x00000000005b72e0 in G_InitNew (mapname=0x1e130bc "MAP02",
bTitleLevel=false)
at /home/chris/Desktop/gzdoom_svn/src/trunk/src/g_level.cpp:1863
#7 0x00000000005b75e0 in G_DoNewGame ()
at /home/chris/Desktop/gzdoom_svn/src/trunk/src/g_level.cpp:1694
#8 0x00000000005ae613 in G_Ticker ()
at /home/chris/Desktop/gzdoom_svn/src/trunk/src/g_game.cpp:889
#9 0x000000000058f6b0 in TryRunTics ()
at /home/chris/Desktop/gzdoom_svn/src/trunk/src/d_net.cpp:1845
#10 0x000000000058814b in D_DoomLoop ()
at /home/chris/Desktop/gzdoom_svn/src/trunk/src/d_main.cpp:808
#11 0x00000000005894af in D_DoomMain ()
at /home/chris/Desktop/gzdoom_svn/src/trunk/src/d_main.cpp:2542
#12 0x0000000000555c90 in main (argc=1, argv=0x7fff403b6838)
at /home/chris/Desktop/gzdoom_svn/src/trunk/src/sdl/i_main.cpp:269
The program is running. Exit anyway? (y or n)
I'm still looking at this and will post anything else useful I find.
Posted: Thu Aug 07, 2008 0:12
by Graf Zahl
The missing lump seems to be acs/strfhelp.o. For some reason it wasn't added to the SVN. Fixed.