FORUM ARCHIVED

Linux 64-bit Crash after certain amount of time ingame [with Backtrace]

Discussion in 'Bugs' started by Doomicide, Jan 10, 2012.

  1. Doomicide

    Doomicide Member

    I'm running DoD 1.0.9b rev 2 from desura on an Arch64 Machine. I got two save files created with this version and both of them crash after a certain amount of time/turns in game. So I am able to walk around and play for some time before the game just crashes. Here's the gdb output + a backtrace + some other stuff that may or may not be useful:
    Code:
    Program received signal SIGSEGV, Segmentation fault.
    0x00000000005360d4 in DirectorTick() ()
    (gdb) backtrace fu
    funlockfile  futimens    futimes      futimesat   
    (gdb) backtrace full
    #0  0x00000000005360d4 in DirectorTick() ()
    No symbol table info available.
    #1  0x0000000000411fde in GameTick() ()
    No symbol table info available.
    #2  0x00000000005151c5 in ParsePlayerInput() ()
    No symbol table info available.
    #3  0x00000000004a045f in Mainloop() ()
    No symbol table info available.
    #4  0x00000000004a071d in PlayGameWithLoadFilename(std::string) ()
    No symbol table info available.
    #5  0x00000000004a354f in main ()
    No symbol table info available.
     
    (gdb) info registers
    rax            0x3e4780901044873360
    rbx            0x00
    rcx            0x11a77250296186448
    rdx            0x11a77250296186448
    rsi            0x11a77278296186488
    rdi            0x7ffff6cbe620140737333945888
    rbp            0x00x0
    rsp            0x7fffffffe4b00x7fffffffe4b0
    r8            0x00
    r9            0xfe5a8c0266709184
    r10            0x80ea588448600
    r11            0x11
    r12            0x7fffffffe4b0140737488348336
    r13            0x11834320293815072
    r14            0x4c93bc080296896
    r15            0x00
    rip            0x5360d40x5360d4 <DirectorTick()+276>
    eflags        0x210206[ PF IF RF ID ]
    cs            0x3351
    ss            0x2b43
    ds            0x00
    es            0x00
    fs            0x00
    gs            0x00
     
    => 0x5360d4 <_Z12DirectorTickv+276>:mov    0x18(%rax),%r8d
      0x5360d8 <_Z12DirectorTickv+280>:test  %r8d,%r8d
      0x5360db <_Z12DirectorTickv+283>:jne    0x5360b8 <_Z12DirectorTickv+248>
      0x5360dd <_Z12DirectorTickv+285>:mov    $0x18,%edi
      0x5360e2 <_Z12DirectorTickv+290>:callq  0x4055a8 <_Znwm@plt>
      0x5360e7 <_Z12DirectorTickv+295>:cmp    $0xfffffffffffffff0,%rax
      0x5360eb <_Z12DirectorTickv+299>:je    0x5360f0 <_Z12DirectorTickv+304>
      0x5360ed <_Z12DirectorTickv+301>:mov    %ebx,0x10(%rax)
      0x5360f0 <_Z12DirectorTickv+304>:mov    %rsp,%rsi
      0x5360f3 <_Z12DirectorTickv+307>:mov    %rax,%rdi
      0x5360f6 <_Z12DirectorTickv+310>:callq  0x405118 <_ZNSt15_List_node_base7_M_hookEPS_@plt>
      0x5360fb <_Z12DirectorTickv+315>:mov    0x0(%r13),%rdx
      0x5360ff <_Z12DirectorTickv+319>:mov    0x8(%r13),%rsi
      0x536103 <_Z12DirectorTickv+323>:jmp    0x5360b8 <_Z12DirectorTickv+248>
      0x536105 <_Z12DirectorTickv+325>:nopl  (%rax)
      0x536108 <_Z12DirectorTickv+328>:mov    (%rsp),%rcx
     
    gdb) thread apply all backtrace
     
    Thread 2 (Thread 0x7ffff1d39700 (LWP 24852)):
    #0  0x00007ffff69fb8b3 in poll () from /lib/libc.so.6
    #1  0x00007ffff25f30ca in ?? () from /usr/lib/libasound.so.2
    #2  0x00007ffff25f7644 in ?? () from /usr/lib/libasound.so.2
    #3  0x00007ffff2601e8b in snd_pcm_mmap_writei () from /usr/lib/libasound.so.2
    #4  0x00007ffff7b78853 in ?? () from /usr/lib/libSDL-1.2.so.0
    #5  0x00007ffff7b4b980 in ?? () from /usr/lib/libSDL-1.2.so.0
    #6  0x00007ffff7b53e15 in ?? () from /usr/lib/libSDL-1.2.so.0
    #7  0x00007ffff7b97739 in ?? () from /usr/lib/libSDL-1.2.so.0
    #8  0x00007ffff670be7a in start_thread () from /lib/libpthread.so.0
    #9  0x00007ffff6a03bad in clone () from /lib/libc.so.6
    #10 0x0000000000000000 in ?? ()
     
    Thread 1 (Thread 0x7ffff7fd5740 (LWP 24850)):
    #0  0x00000000005360d4 in DirectorTick() ()
    #1  0x0000000000411fde in GameTick() ()
    #2  0x00000000005151c5 in ParsePlayerInput() ()
    #3  0x00000000004a045f in Mainloop() ()
    #4  0x00000000004a071d in PlayGameWithLoadFilename(std::string) ()
    #5  0x00000000004a354f in main ()
    
     
  2. alamar

    alamar Member

    I experience the same problem with same backtrace on linux 64-bit.
     
  3. lvomrm

    lvomrm Member

    I also got that problem on archlinux.
    A certain amount of time there is no problem, and then suddenly i get a seg-fault (sometimes when using stairs, sometimes when opening a traesure sometimes when taking a side quest.).
    The strange thing is, that after the game crashed once and i restart it the next crash comes way earlyer.
     
  4. proteusmoteus

    proteusmoteus Member

    Dredmor 1.0.9 on linux 64 bit w/ same problem. At first I thought it was this problem because it seemed to start happening on level 4 (guessed rare badly cased monsters spawning in), so I made this script to fix the case errors (the patch file applied badly). However it made no difference.

    Now I am confident it is a saved game corruption bug. In Desura eventually the saved game would crash after some random amount of time (never before a save, so may need to try minimizing instead of quitting). Trying the HIB build the same save would crash just trying to load. Starting fresh with HIB eventually got a game that wouldnt load. Loading in Desura once that happened got the same Desura behavior, crash after random amount of time.

    Wine steam acts the same as Desura (crash after random amount of play), but I havent started a game in wine steam to see if it will corrupt the save as HIB and Desura do.
     
  5. Eddward

    Eddward Member

    I haven't attempted to get a trace yet, but the game has been very crash happy for me as well. I'm running linux 32bit. In my current saved game, I have a quest to kill a number of monsters. There is one particular monster for this quest that if I kill it, the game will crash every time. Should I upload it?
     
  6. Nicholas

    Nicholas Technology Director Staff Member

    I am slightly concerned that I have no idea why save games are being corrupted; specifically, this is caused by people's save games getting incorrect room neighbour assignments after saving and reloading. It is a mystery.

    That said, I've added code so that if you load a save game *with* incorrect room neighbour assignments, it just fixes them, and I'm changing how we load and save room assignments so that we no longer try to fix pointers up (ewww....) The combination of the two fixes my example crashing save games, and we will roll this into 1.0.9 REV C.
     
  7. Nicholas

    Nicholas Technology Director Staff Member

    Out of curiousity, does this only happen to people who take quests?
     
  8. Nicholas

    Nicholas Technology Director Staff Member

    And, of course, I just realized why this is on the bus. Pointers on Linux 64-bit? Are 64-bit! Hence,

    fwrite(&pointer, 4, 1, fp);

    is not going to get me very much mileage, is it...?

    Still, that's the only 64-bit compatibility issue we've found to date. I wonder how long that's been lurking around? This isn't new code...
     
  9. Doomicide

    Doomicide Member

    I always take quests.
    After having the third char with this problem, it appears to me as being randomly level dependent. Meaning it starts to happen when entering some level (e.g.2, 3, 4) and stops when leaving it.
     
  10. NickolasFox

    NickolasFox Member

    Gentoo Linux x86_64 the same problem with this version, game crushes with tracelog after some time ingame.
    I got crash after going room with a lot of stuff on 1st level by going to satanic pentagram on the floor.
    32bit version crushes too
     
  11. Tcepsa

    Tcepsa Member

  12. Eddward

    Eddward Member

    Nicholas, sorry to pry, but this has been driving me nuts. How is saving a pointer not dangerous? I'm assuming you are saving it in the saved game to restore later. How can you know the thing it points to will be in the same place when you reload the game? It seem what every space you allocate later to restore into could be anywhere.
     
  13. Since the official patch isn't out yet, a workaround is to run the game in 32-bit mode

    Code:
    $ linux32 ./Dredmor-x86
    I used to see crashes every 10min or so. That hasn't happened since I started running the game as above.