Dom 3.23b GUI freeze (linux)

[duncanshriek]

For the third or fourth time I suffered now a GUI freeze. This time I was running dom3_amd64 under the debugger, with the small hope I might be able to recover from there. But no luck, since the chances are small without debugging symbols in the exe.

It happened while scripting spells for a commander. Not hanging, just dom3 is frozen without any CPU activity. Here's the backtrace, uninformative as it is:

#0 0x00007f1efb6cbe50 in __nanosleep_nocancel () from /lib/libpthread.so.0
#1 0x000000000040b8d6 in ?? ()
#2 0x00000000004b6050 in ?? ()
#3 0x000000000045da52 in ?? ()
#4 0x00000000004e54fd in ?? ()
#5 0x00000000004e889c in ?? ()
#6 0x00000000004ec05b in ?? ()
#7 0x00000000004ec605 in ?? ()
#8 0x00000000004d3bb3 in ?? ()
#9 0x00000000004084af in ?? ()
#10 0x00007f1efb0db1c4 in __libc_start_main () from /lib/libc.so.6
#11 0x0000000000404909 in ?? ()
#12 0x00007fff03f6e3e8 in ?? ()
#13 0x0000000000000000 in ?? ()


Are the developers reading here? Or should I email that somewhere?

[Johan K]

I (dom3 developer) am reading this forum quite often, so posting here works fine. But the backtrace was useless though

If you get a backtrace with less ?? then I would be glad to see it and I might even figure out what went wrong. Running without sound (-d) might help too so you don't get a backtrace of the sound thread by mistake.

[lch]

Johan, as he says these ?? are because the debugging symbols are stripped from the binary. If I understood him correctly, then all the libs that he uses are compiled with full debugging on. Though address-wise, the "#12 0x00007fff03f6e3e8" seems to be a lib call instead of game code, judging from the pointer address, and the last one seems to be a null-pointer exception to me, or is that wrong?

[duncanshriek]

Originally Posted by Johan K

I (dom3 developer) am reading this forum quite often, so posting here works fine. But the backtrace was useless though

If you get a backtrace with less ?? then I would be glad to see it and I might even figure out what went wrong. Running without sound (-d) might help too so you don't get a backtrace of the sound thread by mistake.

Good, I could provide you with some additional infos:

- That error was most propably newly introduced with 3.23. I played a lot with earlier versions and never had that before.

- I absolutely never play with game sound (I have my own taste :-))

- The ?? lines of the backtrace are not completely useless: the 400000x address range is in the dom3 app, not in any dynamic library. So the nanosleep_nocancel() was directly called by dom3

- the 2 last -d debug log lines before the freeze:
ustatbox unr4624 sel(nil)
guiarea 14 x 175.000000 y 500.869507 450.000000x32.670013 alpha 0.200000