VOGONS


First post, by Serious Callers Only

User metadata
Rank Member
Rank
Member

even just calling it 'dosbox' in a dir without a dosbox.configue file

[New Thread 0x7fffea813700 (LWP 26089)]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff613748e in std::string::compare(char const*) const ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0 0x00007ffff613748e in std::string::compare(char const*) const ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1 0x00000000005ee2d8 in operator==<char, std::char_traits<char>, std::allocator<char> > (__rhs=0x62a1b2 "PROGRAM_MOUNT_CDROMS_FOUND",
__lhs=<error reading variable: Cannot access memory at address 0x35>)
at /usr/include/c++/4.9/bits/basic_string.h:2540
#2 MSG_Add (_name=_name@entry=0x62a1b2 "PROGRAM_MOUNT_CDROMS_FOUND",
_val=_val@entry=0x62a4dc "CDROMs found: %d\n") at messages.cpp:49
#3 0x00000000004a8053 in DOS_SetupPrograms () at dos_programs.cpp:1485
#4 0x000000000049d7cf in DOS (configuration=0x38ffdb0, this=0x3985fd0)
at dos.cpp:1228
#5 DOS_Init (sec=0x38ffdb0) at dos.cpp:1248
#6 0x00000000005f5f31 in Section::ExecuteInit (this=0x38ffdb0,
initall=initall@entry=true) at setup.cpp:748
#7 0x00000000005f5f76 in Config::Init (this=0x7fffffffdeb0) at setup.cpp:732
#8 0x000000000040a534 in main (argc=<optimized out>, argv=<optimized out>)
at sdlmain.cpp:2072

Hope this is the cause of the mystery crashes and it can be traced. Hopefully not back at my environment being fucked.

Reply 1 of 12, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Try a clean SVN (no munt stuff) and without debug first.

The MSG_Add code seems okay to me at first glance. (where your backtrace points at)
It isn't the first time when this function is called either ( which is with CONFIG_FULLSCREEN )

Water flows down the stream
How to ask questions the smart way!

Reply 2 of 12, by Serious Callers Only

User metadata
Rank Member
Rank
Member

This is a clean svn. Without debug things work, until i have those mysterious crashes i've been complaining about in the munt topic in some games.

I think there might be something fucked in my environment. The backtrace doesn't make much sense to me either.

Reply 3 of 12, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Looks like a 64bit build. Maybe that's where the wrongness starts. Does it crash as well when you set core to manual (instead of auto or dynamic)?

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 4 of 12, by Serious Callers Only

User metadata
Rank Member
Rank
Member

Yup. I changed the main config file to set core to simple and started with ./dosbox -userconf (although i can't scroll up to see if the config file chosen is the right one because the debugger window cleared the console).

edit: i think the output of configure might be showing the problem.

./configure 
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make sets $(MAKE)... (cached) yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking for ranlib... ranlib
checking for sdl-config... /usr/bin/sdl-config
checking for SDL - version >= 1.2.0... yes
checking SDL version only being 1.2.X... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for size_t... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking size of unsigned char... 1
checking size of unsigned short... 2
checking size of unsigned int... 4
checking size of unsigned long... 8
checking size of unsigned long long... 8
checking size of int *... 8
checking for stdlib.h... (cached) yes
checking for sys/types.h... (cached) yes
checking for sys/socket.h... yes
checking for netinet/in.h... yes
checking for pwd.h... yes
checking if environ can be included... yes
Show last 78 lines
checking if environ can be linked... yes
checking if dirent includes d_type... yes
checking for powf in libm... yes
checking for library containing clock_gettime... none required
checking if compiler allows __attribute__... yes
checking if compiler allows __attribute__((always_inline)) ... yes
checking if compiler allows __attribute__((fastcall)) ... no
checking if compiler allows __builtin_expect... yes
checking if compiler supports -mno-ms-bitfields... yes
checking for ALSA CFLAGS...
checking for ALSA LDFLAGS... -lasound -lm -ldl -lpthread
checking for libasound headers version >= 0.9.0... found.
checking for snd_ctl_open in -lasound... yes
checking whether byte ordering is bigendian... no
checking for target cpu type... x86-64 bit compatible
checking whether x86 dynamic cpu core will be enabled... no
checking whether recompiling cpu core will be enabled... yes
checking whether fpu emulation will be enabled... yes
checking whether the x86/x64 assembly fpu core will be enabled... yes
checking whether to enable unaligned memory access... yes
checking png.h usability... yes
checking png.h presence... yes
checking for png.h... yes
checking for png_get_io_ptr in -lpng... yes
checking SDL_net.h usability... yes
checking SDL_net.h presence... yes
checking for SDL_net.h... yes
checking for SDLNet_Init in -lSDL_net... yes
checking for main in -lX11... yes
checking X11/XKBlib.h usability... yes
checking X11/XKBlib.h presence... yes
checking for X11/XKBlib.h... yes
checking for XKBlib support... yes
checking for main in -lGL... yes
checking for main in -lopengl32... no
checking GL/gl.h usability... yes
checking GL/gl.h presence... yes
checking for GL/gl.h... yes
checking whether opengl display output will be enabled... yes
checking SDL_sound.h usability... yes
checking SDL_sound.h presence... yes
checking for SDL_sound.h... yes
checking for Sound_Init in -lSDL_sound... yes
checking for Sound_Seek in -lSDL_sound... yes
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking for mprotect... yes
checking for setpriority support... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating src/cpu/Makefile
config.status: creating src/cpu/core_full/Makefile
config.status: creating src/cpu/core_normal/Makefile
config.status: creating src/cpu/core_dyn_x86/Makefile
config.status: creating src/cpu/core_dynrec/Makefile
config.status: creating src/debug/Makefile
config.status: creating src/dos/Makefile
config.status: creating src/fpu/Makefile
config.status: creating src/gui/Makefile
config.status: creating src/hardware/Makefile
config.status: creating src/hardware/serialport/Makefile
config.status: creating src/ints/Makefile
config.status: creating src/libs/Makefile
config.status: creating src/libs/zmbv/Makefile
config.status: creating src/libs/gui_tk/Makefile
config.status: creating src/misc/Makefile
config.status: creating src/shell/Makefile
config.status: creating src/platform/Makefile
config.status: creating src/platform/visualc/Makefile
config.status: creating visualc_net/Makefile
config.status: creating include/Makefile
config.status: creating docs/Makefile
config.status: creating config.h
config.status: executing depfiles commands

is that "checking host system type... x86_64-unknown-linux-gnu" thing normal? Wasn't it p much supposed to pinpoint my cpu type at least?

Last edited by Serious Callers Only on 2015-07-30, 12:37. Edited 1 time in total.

Reply 5 of 12, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

I think the host system type doesn't matter, the important parts, x86_64 and linux, are found.

Does it crash with core normal?

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 6 of 12, by Serious Callers Only

User metadata
Rank Member
Rank
Member

It crashes with all cores.

For what it's worth i managed to run the Azrael's Tear bug through a debugger (with normal svn - without patches, just built locally with ./autogen; ./configure; make - non-debug dosbox for obvious reasons). It gave me this

terminate called after throwing an instance of 'char*'
[New Thread 0x7fffeaa37700 (LWP 24306)]

Program received signal SIGABRT, Aborted.
0x00007ffff5c0e267 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:55
55 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007ffff5c0e267 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:55
#1 0x00007ffff5c0feca in __GI_abort () at abort.c:89
#2 0x00007ffff652206d in __gnu_cxx::__verbose_terminate_handler() ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff651fee6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007ffff651ff31 in std::terminate() ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007ffff6520149 in __cxa_throw ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00000000005e999f in E_Exit (
format=format@entry=0x60c68b "FPU stack overflow") at support.cpp:183
#7 0x0000000000474b70 in FPU_PREP_PUSH ()
at core_dynrec/../../fpu/fpu_instructions_x86.h:960
#8 0x00007fffebc76532 in ?? ()
#9 0x00007fffffffa8e8 in ?? ()
#10 0x00007fffeba1c043 in ?? ()
#11 0x0000000000195afb in ?? ()
#12 0x0000000000489f16 in CPU_Core_Dynrec_Run () at core_dynrec.cpp:231
#13 0x000000000040a5a7 in Normal_Loop () at dosbox.cpp:136
#14 0x000000000040af3e in DOSBOX_RunMachine () at dosbox.cpp:260
#15 0x0000000000412ec1 in CALLBACK_RunRealInt (intnum=intnum@entry=33 '!')

Reply 7 of 12, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Ah that is pretty interesting. A game that triggers that.
I added that.
What do I need to do to reproduce that ?

Water flows down the stream
How to ask questions the smart way!

Reply 8 of 12, by Serious Callers Only

User metadata
Rank Member
Rank
Member

It's semi random, but happens p quick most times. Often just in the first room less often in the 3rd or 4th room after shooting a guy and speaking to another guy. It seems to happen often when speaking to that guy if it didn't in the first room. You can also wait on the first room and it seems most time it crashes (probably due to the critters moving around).
I was playing with dos32a replacing the packed dos4g, but it also happens in the untouched executable install.

Dosbox 0.74-4 from the repositories doesn't have this problem

Reply 9 of 12, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

yeah. I added that exit condition. I am surprised it triggers in a real game, so maybe some fpu register isn't cleared by dosbox correctly. Or they would rely on the stack overflow exception, but I don't see why a game would do that as it isn't the greatest for speed.

Water flows down the stream
How to ask questions the smart way!

Reply 10 of 12, by Serious Callers Only

User metadata
Rank Member
Rank
Member

I think there is a dos demo around the net.
http://download.cnet.com/Azrael-s-Tear-demo/3 … 4-10000236.html
execute in dos, use install.bat, create a fake dir cdrom for the start bat not to freak out.

But i couldn't get this one to crash so its probably useless.

Reply 11 of 12, by Serious Callers Only

User metadata
Rank Member
Rank
Member

I did find that the game doesn't crash with 32bits dosbox (my ppa build). But i think it's still a regression, since it didn't either with (i believe, because i never specified :i386) dosbox 0.74-4 64 bits build from the ubuntu repositories.

Reply 12 of 12, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Yeah. I have to see if I can find the game.
The game regressed, but the exit condition that was added, makes sense. So maybe something else is going wrong.

Water flows down the stream
How to ask questions the smart way!