Okay, I started adding option one section at a time and found out the specific option on where it crashes.

When I have:

memsize=32

enabled under the [dosbox] section, dosbox will crash. All other options seem to work fine.

dosbox doesn't come with a default configfile as you can create one
try typing this in dosbox
config -writeconf dosbox.conf

then exit dosbox and look in the cwd
crashes on memsize=32...
hmm i got that as well.

1[dosbox]
2# language -- Select another language file.
3# memsize -- Amount of memory dosbox has in megabytes.
4# machine -- The type of machine tries to emulate.
5#            You can select from auto,hercules,tandy,vga.
6                                                                                                    
7language=
8machine=auto
9memsize=32

Works fine overhere.

This is a wierd bug, when I compile dosbox with debugging enabled the bug goes away. Compiling normally the bug shows up again.

setting memsize to anything less than 32 works, setting it to 32 or greater causes the crash.

odd
compiling dosbox with
./configure --disable-dynamic-x86 CXXFLAGS="-02"
makes a bineary that works with memsize=64

when ommiting the disable-.....
the bineary still works fine.
I use GCC
qbix@Het-Beest:~/dosbox/src$ g++ --version
g++ (GCC) 3.3.2 (Debian)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I tried compiling with the above configure options and I still get the error. I even tried compiling with g++296 to see if it was a compiler bug and that didn't help either. Below is a list of libraries its linked against. Perhaps its an SDL bug? What version of SDL are you using?

$ ldd ./dosbox
libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x40017000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x400a6000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x400f7000)
libz.so.1 => /usr/lib/libz.so.1 (0x4011a000)
libSDL_net-1.2.so.0 => /usr/lib/libSDL_net-1.2.so.0 (0x4012b000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4012f000)
libm.so.6 => /lib/i686/libm.so.6 (0x401e7000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4020a000)
libc.so.6 => /lib/i686/libc.so.6 (0x40212000)
libdl.so.2 => /lib/libdl.so.2 (0x4034d000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40350000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4042e000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[chris@lothlorien src]$ g++ --version
g++ (GCC) 3.3.2 20031022 (Red Hat Linux 3.3.2-1)

I ran dosbox inside gdb and did a stack trace after the crash, and this is what I got:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 6672)]
0x408a36cc in Arts::StartupManager::startup() () from /usr/lib/libmcop.so.1
(gdb) bt
#0 0x408a36cc in Arts::StartupManager::startup() () from /usr/lib/libmcop.so.1
#1 0x40889a57 in Arts::Dispatcher::Dispatcher(Arts::IOManager*, Arts::Dispatcher::StartServer) () from /usr/lib/libmcop.so.1
#2 0x40456b15 in arts_backend_init () from /usr/lib/libartscbackend.so.0
#3 0x40093776 in arts_init () from /usr/lib/libartsc.so.0
#4 0x400281d9 in SDL_FreeWAV () from /usr/lib/libSDL-1.2.so.0
#5 0x40023e9e in SDL_OpenAudio () from /usr/lib/libSDL-1.2.so.0
#6 0x0807ac5c in MIXER_Init(Section*) ()
#7 0x080999b2 in Config::Init() ()
#8 0x0808592d in main ()
(gdb) quit

So I decided to turn on the arts sound server in KDE and this fixed the problem!

Not sure if its a memory leak in SDL or dosbox which is causing this, perhaps running it with a memory leak detector will provide some clues. Anyway, it seems I've found an acceptable work-around for now. 😁

XulChris wrote:

So I decided to turn on the arts sound server in KDE and this fixed the problem!

er, that should be "So I decided to turn > OFF < the arts sound server...

glad you found the cause

I use gnome 2.4 so no arts for me.
I think sdl might be to blame but who am I I know little of sdl internals.

Dosbox has quite some memory leaks but those shouldn't be troublesome when starting up.

Qbix wrote:

Dosbox has quite some memory leaks but those shouldn't be troublesome when starting up.

At least you admit it. 😀

yeah yeah 😉
I plug now and then one.
There aren't any big ones left
(ps: i left the dynamic core out of this statement (just kidding harekiet))

The dynamic core doesn't leak one byte of memory....more like a megabytes 😉

In my experience, most common crash reason is when cpu core finishes it's job with callback number greater than CB_MAX for some reason.
"Normal Loop" then tries to execute callback function from random address and crashes.
e.g. Digitrakker has this behavior.