Duke4.net Forums: Eduke32 crashing when loading a DukePlus map save - Duke4.net Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Eduke32 crashing when loading a DukePlus map save

User is offline   Ripper 

#1 Posted 03 June 2013 - 03:44 PM

It is simple: When I load a save from DukePlus on Eduke32, the game crashes.

I tried with the lastest source so far(r3850) and same result.

OS: Ubuntu 12.10 64x (Linux Mint Distro)


eduke32.log
Spoiler


EDIT: Better backtrace
Backtrace
Spoiler


This post has been edited by Ripper: 03 June 2013 - 04:57 PM

0

User is offline   Hendricks266 

  • Weaponized Autism

  #2 Posted 03 June 2013 - 04:31 PM

That backtrace doesn't reveal much. You may need to compile EDuke32 with the "-g" option. With our build system, that would be:

make RELEASE=0

This post has been edited by Hendricks266: 03 June 2013 - 04:31 PM

0

User is offline   Ripper 

#3 Posted 03 June 2013 - 04:46 PM

View PostHendricks266, on 03 June 2013 - 04:31 PM, said:

That backtrace doesn't reveal much. You may need to compile EDuke32 with the "-g" option. With our build system, that would be:

make RELEASE=0


I already tried that and running with gdb causes the eduke32 to freeze. Doing that makes me stuck in the eduke32. If I try a "killall" or a "kill" solution, it makes eduke32 screen black. Doing the same with gdb crashes my graphical server.

Gotta try again and upload a few printscreens.

EDIT: GO IT!

Program received signal SIGSEGV, Segmentation fault.
0x000000000058e755 in filnamcmp (st0=0x7fffffffd7a1 "DukePlus/joke.voc", 
    st1=0x6c4d1514 <Address 0x6c4d1514 out of bounds>) at src/kplib.c:2591
2591	        ch1 = st1[i]; if ((ch1 >= 'a') && (ch1 <= 'z')) ch1 -= 32;


Hope it helps.

This post has been edited by Ripper: 03 June 2013 - 04:53 PM

0

User is offline   Helixhorned 

  • EDuke32 Developer

#4 Posted 04 June 2013 - 07:30 AM

First, your log reveals that your DukePlus installation resides on a case-sensitive file system. That's fine, but modders around here don't always take care to match file name case in the resource definition files (DEFs) with those on the FS, making EDuke32 fail to find some resources. I'm attaching a patch that fixes this, against DukePlus release 2013-01-05. I don't know if that will fix the crash/inifinite loop/whatever in your case, but it's good to sanitize this stuff first.

Does it happen when loading an arbitrary savegame, such as one of the HUB map? I'm running Linux/x64 too, and specifically tested saving/loading in DukePlus a while ago. I didn't encounter any errors then.

View PostRipper, on 03 June 2013 - 04:46 PM, said:

I already tried that and running with gdb causes the eduke32 to freeze.

You can press Ctrl-C to make the process being debugged by GDB reveice a SIGINT, stopping it whatever it was doing at that time.

Quote

Doing the same with gdb crashes my graphical server.

Hhm, that shouldn't happen. Anything interesting from the logs? (/var/log/Xorg* maybe?)

Attached File(s)


1

User is offline   Ripper 

#5 Posted 04 June 2013 - 05:42 PM

View PostHelixhorned, on 04 June 2013 - 07:30 AM, said:

Does it happen when loading an arbitrary savegame, such as one of the HUB map?


No, it doesn't. Very strange indeed.

Quote

You can press Ctrl-C to make the process being debugged by GDB reveice a SIGINT, stopping it whatever it was doing at that time.

Hhm, that shouldn't happen. Anything interesting from the logs? (/var/log/Xorg* maybe?)



It was my eduke32 binary with '-g' flag that did this. It was somewhat corrupted, I suppose. Linked a new one and it debbuged very horrorshow.

Sorry, but what am I suppose to do with that file? I had never applied a patch to eduke32 or it mods.

This post has been edited by Ripper: 04 June 2013 - 05:52 PM

0

User is offline   Helixhorned 

  • EDuke32 Developer

#6 Posted 05 June 2013 - 11:27 AM

View PostRipper, on 04 June 2013 - 05:42 PM, said:

Sorry, but what am I suppose to do with that file? I had never applied a patch to eduke32 or it mods.

From the DukePlus directory, run
patch -p1 --dry-run < 0001-DukePlus-Fix-case-in-DEFs.patch.txt

If the dry run shows everything OK, remove that option to patch it for real.
0

User is offline   LeoD 

  • Duke4.net topic/3513

#7 Posted 06 June 2013 - 03:50 AM

View PostRipper, on 04 June 2013 - 05:42 PM, said:

Sorry, but what am I suppose to do with that file? I had never applied a patch to eduke32 or it mods.
If you haven't figured it out yet, you can alternatively copy the DukePlus-2.35-NixFix (follow my signature) over your DukePlus installation.
0

User is offline   Ripper 

#8 Posted 12 June 2013 - 06:42 PM

Sorry. I couldn't reply to this because of work issues. None of the solutions provided had any good effect. The game still crashing when I'm loading those saves.


BUT I have a new things to report:


Have figured out something interesting.
The save files that eduke32 crashes on have 2.0mB or more. Files under that number load without any problem!

The same thing happens with ANY episode, even the vanila ones! If the save has more than 2.0mb, it crashes.


And the most strange thing of today:

I build the today's new revision (r3875). I try to load the same saves with 2.0mb, with no sucess.

Then, I build the debug version of that revision. With it I could load those saves without problem. It worked!

But I can't play with the debug version. It has no mouselock whatsoever. Is a pain to shoot the monsters.


Please guys, fix this. You guys rock doing that project. I'll help you in everyway I can! :lol:


EDIT:

I found where is the problem and "solved" it for now, but I didn't solve it using the best way, if you know what I mean.

After toying around building the release and debug versions, I descovered the source of the problem. Is in the eobj Folder, where the Linux Shared Objects are:

Posted Image

Using the debug version eobj folder I can load my saves, but with the release version I can't!

Then, I found the sdl shared object that controls the mouse lock.

Posted Image

Just repleaced the debug version with the release version and now I can load my saves and play the game!

Hope this can pinpoint the problem for the devs. It is something in the eobj folder, has to do with the Linux port.

This post has been edited by Ripper: 12 June 2013 - 07:14 PM

0

User is offline   Helixhorned 

  • EDuke32 Developer

#9 Posted 13 June 2013 - 12:58 AM

View PostRipper, on 12 June 2013 - 06:42 PM, said:

Have figured out something interesting.
The save files that eduke32 crashes on have 2.0mB or more. Files under that number load without any problem!

The same thing happens with ANY episode, even the vanila ones! If the save has more than 2.0mb, it crashes.

That sounds like a fixed-sized buffer gets written beyond its bounds. Could you upload the "bad" savegame here or to an external site? Or better, is there a quick way of getting to a state producing such a savegame in DukePlus? Maybe there's already something bad happening at save time.
0

User is offline   Ripper 

#10 Posted 13 June 2013 - 04:18 AM

View PostHelixhorned, on 13 June 2013 - 12:58 AM, said:

Could you upload the "bad" savegame here or to an external site?



Sure, here is the file. dukesav1.esv

Quote

That sounds like a fixed-sized buffer gets written beyond its bounds.


I don't know if I already said it, but the crash is a buffer overflow. So, yeah, it's just like you said.

Quote

is there a quick way of getting to a state producing such a savegame in DukePlus?


Not hard at all. Just play any DukePlus map with HRP(and dukeplus of course). I think the textures makes the save file bigger because of their data. But this shouldn't be a problem.
That little buffer size shouldn't be bigger?



EDIT:

The SAME problem just happened with Duke Nukem Forever 2013 mod. And the scenario is just pretty the same: 2.0mb or more files crash my eduke32. :lol: What I don't get it is why the buffer of savefiles is dynamic (or, at least, bigger) in Debug version but has that limit of 2.0mb in Release version?

This post has been edited by Ripper: 13 June 2013 - 04:26 AM

0

User is offline   LeoD 

  • Duke4.net topic/3513

#11 Posted 13 June 2013 - 07:08 AM

View PostRipper, on 13 June 2013 - 04:18 AM, said:

What I don't get it is why the buffer of savefiles is dynamic (or, at least, bigger) in Debug version but has that limit of 2.0mb in Release version?
The debug version is affected as well, at least for me: loading your esv deletes/overwrites my key bindings in settings.cfg.
0

User is offline   Helixhorned 

  • EDuke32 Developer

#12 Posted 13 June 2013 - 09:51 AM

View PostRipper, on 13 June 2013 - 04:18 AM, said:

Sure, here is the file. dukesav1.esv

Awesome! I was able to reproduce the crash and pinpoint the responsible piece of code (it's Ken's decompression routines in cache1d.c). This crash should be gone with r3880.

Quote

Not hard at all. Just play any DukePlus map with HRP(and dukeplus of course). I think the textures makes the save file bigger because of their data.

No, textures don't get saved. Think about how much that would bloat the resulting savegame files -- their size could easily rise into hundreds of megabytes.

Quote

That little buffer size shouldn't be bigger?

Yes, that's how I "corrected" the problem, but as I noted in the commit log, it hardly deserves to be called a fix. Statically allocated buffers should always be as large as needed in the worst case -- and that bound absolutely has to be known. If it's too small, badness ensues like in this case.[1] If it's too large, it's a sign that the programmer didn't calculate the exact bound and determined it by "hit or miss", which is a sure sign of code smell.

[1]Caveat: I have written such bad code myself and it's still in EDuke32. It's in the demo playback code though, which is a little underused, I'd guess.

Quote

EDIT:

The SAME problem just happened with Duke Nukem Forever 2013 mod. And the scenario is just pretty the same: 2.0mb or more files crash my eduke32. :lol: What I don't get it is why the buffer of savefiles is dynamic (or, at least, bigger) in Debug version but has that limit of 2.0mb in Release version?

I think the 2MB number is coincidence -- maybe it's correlated, but it doesn't directly relate to the cause.

The buffer sizes however do not in general differ between the Debug and Release versions. In fact, for the most part, exactly the same C source is compiled, exceptions being only debugging code itself, or run-time checks (such as assertions) interspersed with the normal code.

The reason why you were experiencing the crash on one build but not another is that out-of-bounds accesses are undefined behavior in C. Thus the C compiler is in no way obliged to emit code that does anything particular -- such as crashing the program -- when such a behavior occurs. I have written about undefined behavior and its sometimes surprising implications before (and provided links to articles from whom I learned all this). Just do a phrase search for "undefined behavior" (i.e. keep the quotes) in the extended search dialog.
0

User is offline   Ripper 

#13 Posted 13 June 2013 - 10:02 AM

Fixed in r3883! Thank you helixhorned!

How I can help the project in a more effective way? I do know some C coding, how to identify bugs and some SDL. Maybe I can be useful.

This post has been edited by Ripper: 13 June 2013 - 10:25 AM

0

User is offline   Plagman 

  • Former VP of Media Operations

#14 Posted 13 June 2013 - 10:55 PM

If you identify a bug, code in a fix and give us the patch, that's plenty useful! We hang out at #eduke32 on Freenode.
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password

Sign in options