kill pulseaudio ?

while it's always a good idea to kill pulseaudio, that didn't resolve it, unfortunately (on my desktop I've still got pulseaudio running, and no problem there). haven't got the abort messages though, just the segfaults. no log in the log file, no other messages.

drives me crazy...

JAL

Would it help if you ran dosbox from inside gdb (or whatever debugger you prefer)?

MiniMax wrote:

Would it help if you ran dosbox from inside gdb (or whatever debugger you prefer)?

I'll give it a try tonight, see what it comes up with.

JAL

Mmm, nothing I can go on. I'm not very versed with gdb, and I don't feel like debugging the entire dosbox, but this is some output from a few startups:

1[New Thread 0xb5bc7b90 (LWP 4163)]om config file /home/kilian/.dosbox/dosbox-0.7
2
3Program received signal SIGSEGV, Segmentation fault.
4[Switching to Thread 0xb77ed6e0 (LWP 4159)]
50xb7b5bdfb in fputs () from /lib/tls/i686/cmov/libc.so.6
6(gdb) 
7
8
9[New Thread 0xb5bcdb90 (LWP 4383)]om config file /home/kilian/.dosbox/dosbox-0.7
10
11Program received signal SIGSEGV, Segmentation fault.
12[Switching to Thread 0xb77f36e0 (LWP 4379)]
130xb7d30b25 in std::string::compare () from /usr/lib/libstdc++.so.6
14(gdb) 
15
16
17[New Thread 0xb5c56b90 (LWP 4391)]om config file /home/kilian/.dosbox/dosbox-0.7
18
19Program received signal SIGSEGV, Segmentation fault.
20[Switching to Thread 0xb787c6e0 (LWP 4387)]
210xb7db9b25 in std::string::compare () from /usr/lib/libstdc++.so.6
22(gdb) 
23
24
25[New Thread 0xb56d6b90 (LWP 4439)]ration.
26
27Program received signal SIGSEGV, Segmentation fault.
28[Switching to Thread 0xb56d6b90 (LWP 4439)]
290xb791e415 in snd_pcm_poll_descriptors_revents () from /usr/lib/libasound.so.2
30(gdb)

JAL

and I don't feel like debugging the entire dosbox

None of those locations is in dosbox. Not that this'd make the debugging easier 😉

bt

and maybe some debug symbols to dosbox
CXXFLAGS=" -O0 -ggdb3" ./configure --enable-debug
or change the -O0 with -O2 and/or go for heavy debug stuff
this makes the backtraces (bt) contain more useful information

h-a-l-9000 wrote:

bt

I believe this rather cryptic post means that if you give the command bt to gbd you will get a backtrace (stacktrace) with information about where the program crashed.

I believe this rather cryptic post

Actually it's the most non-cryptic way of sharing information imo, props to hal 😉

Ok, thank's y'all, I'll try to do some more debugging tonight, if I can find the time (going on holiday this weekend, and there's unfortunately more to it than preparing your laptop for uninterrupted coding 😀).

JAL

wd wrote:

I believe this rather cryptic post

Actually it's the most non-cryptic way of sharing information imo, props to hal 😉

Actually it was pretty cryptic.

A two-character string can't be THAT hard to decrypt.

Running bt (thanks wd 😀) gives the following results for a couple of crashes:

1#0  0xb7a9a078 in strcmp () from /lib/tls/i686/cmov/libc.so.6
2#1  0x0815e5c3 in MAPPER_AddHandler (handler=0x80e0230 <DEBUG_Enable(bool)>, key=MK_pause, mods=2, eventname=0x823caf7 "debugger", buttonname=0x823caee "Debugger")
3    at sdl_mapper.cpp:2076
4#2  0x080e01c1 in DEBUG_Init (sec=0xa93d0e8) at debug.cpp:1976
5#3  0x0821bdc9 in Section::ExecuteInit (this=0xa93d0e8, initall=true) at setup.cpp:728
6#4  0x0821be1b in Config::Init (this=0xbfd771c8) at setup.cpp:712
7#5  0x0815c642 in main (argc=Cannot access memory at address 0x6e
8) at sdlmain.cpp:1807
9
10
11#0  0xb7bdeb25 in std::string::compare () from /usr/lib/libstdc++.so.6
12#1  0x082199f9 in MSG_Add (_name=0x8240d34 "PROGRAM_MOUNT_CDROMS_FOUND", _val=0x8240d22 "CDROMs found: %d\n") at /usr/include/c++/4.3/bits/basic_string.h:2189
13#2  0x080f3f7a in DOS_SetupPrograms () at dos_programs.cpp:1343
14#3  0x080e6c25 in DOS_Init (sec=0xbbf7c18) at dos.cpp:1127
15#4  0x0821bdc9 in Section::ExecuteInit (this=0xbbf7c18, initall=true) at setup.cpp:728
16#5  0x0821be1b in Config::Init (this=0xbf903d58) at setup.cpp:712
17#6  0x0815c642 in main (argc=Cannot access memory at address 0x11
18) at sdlmain.cpp:1807

The first one is from a crash after removing the config file, happening after a number of seconds, the second one repeats after that.

So it seems there's some SDL problem, probably?

JAL

A two-character string can't be THAT hard to decrypt.

HunterZ should have learned the hard way 😉

wd wrote:

A two-character string can't be THAT hard to decrypt.

Indeed, but decrypting it into the right thing requires something additional :p

BitTorrent...no
British Telecom...no
???
Profit!

Turns out it's all about context. Didn't realize that it was in reference specifically to gdb.

Running bt (thanks wd)

I'm innocent, hal's the one!

BitTorrent...no British Telecom...no ??? Profit! […]
Show full quote

BitTorrent...no
British Telecom...no
???
Profit!

Ok you'll maybe even get a prize for decrypting "bt" into "Profit" 😀

Maybe you can put some LOG_MSGs into the MSG_Add in messages.cpp

wd wrote:

Maybe you can put some LOG_MSGs into the MSG_Add in messages.cpp

Ok, see if I can do tomorrow...

JAL

What gcc version is that btw.? And compiling for 32bit? (logs look like that...)