Strife not working in r144

Bugs that have been resolved.

Moderator: Graf Zahl

Locked
User avatar
Enjay
Developer
Developer
Posts: 4748
Joined: Tue Aug 30, 2005 23:19
Location: Scotland
Contact:
Contact Enjay

Strife not working in r144

Post by Enjay »

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:

Code: Select all

MAP02 - AREA  2: town


W_LumpLength: -1 >= NumLumps
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.
Top
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:
Contact Graf Zahl

Post by Graf Zahl »

Works for me. Can you post the startup log?
Top
User avatar
Agent ME
Posts: 229
Joined: Mon Jan 02, 2006 12:39
Contact:
Contact Agent ME

Post 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.
Spoiler: Startup Log
Top
User avatar
Agent ME
Posts: 229
Joined: Mon Jan 02, 2006 12:39
Contact:
Contact Agent ME

Post by Agent ME »

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.
Spoiler: Debug log
Last edited by Agent ME on Tue Aug 05, 2008 6:49, edited 1 time in total.
Top
User avatar
Agent ME
Posts: 229
Joined: Mon Jan 02, 2006 12:39
Contact:
Contact Agent ME

Post by Agent ME »

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.
Spoiler: GDB Stuff
Top
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:
Contact Graf Zahl

Post 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?
Top
User avatar
Nash
Developer
Developer
Posts: 1226
Joined: Sun Sep 25, 2005 1:49
Location: Kuala Lumpur, Malaysia
Contact:
Contact Nash

Post by Nash »

I get the same error as Enjay in my home-compiled GZDoom r148.
Top
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:
Contact Graf Zahl

Post by Graf Zahl »

That information doesn't help me unless somebody tells me which lump causes the problem. It doesn't happen to me.
Top
User avatar
Agent ME
Posts: 229
Joined: Mon Jan 02, 2006 12:39
Contact:
Contact Agent ME

Post by Agent ME »

I set a breakpoint on FWadCollection::LumpLength if lump==-1, and did a backtrace soon as it was paused there:
Spoiler: Backtrace
I'm still looking at this and will post anything else useful I find.
Top
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:
Contact Graf Zahl

Post by Graf Zahl »

The missing lump seems to be acs/strfhelp.o. For some reason it wasn't added to the SVN. Fixed.
Top
Locked

Return to “Closed Bugs”