Compiling a program that only contains:
sleep or sleep 500
Crashes in DOSBox Staging with SIGSEGV.
But compiling/running sleep 1, 1 seems to work just fine.
I also tried to compile/run DOS/isrtimer.bas, DOS/textbuff.bas and graphics/qbsprite.bas
isrtimer.bas crashes in the same manner (SIGSEGV).
textbuff.bas works fine without any crashes.
qbsprite.bas seems to work fine, but crashes (SIGSEGV) after I push any key.
Also DOSBox Staging hangs after this, and the key I just pressed shows up in the DOS console.
Any idea how to solve/debug this?
DOSBox Staging, SLEEP crashes with SIGSEGV
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: DOSBox Staging, SLEEP crashes with SIGSEGV
Since 2 weeks I use latest FreeBASIC version (and Turbo C, QB45, VBDOS...) on a real FreeDOS only PC without any problems so it must be a DOSBox thing.
Maybe wrong setting in the DOSBox config file or a problem with the DPMI service etc.
Or you must run the app DosBox on your Windows 10/11 OS in a more older compatible mode (Windows XP, Windows 7 ...)
Joshy
Maybe wrong setting in the DOSBox config file or a problem with the DPMI service etc.
Or you must run the app DosBox on your Windows 10/11 OS in a more older compatible mode (Windows XP, Windows 7 ...)
Joshy
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: DOSBox Staging, SLEEP crashes with SIGSEGV
I tested latest DOSBox and CWSDPMI for you on my Windows PC and can confirm the trouble.
(but again on a real DOS PC no problems at all)
Joshy
(but again on a real DOS PC no problems at all)
Joshy
Re: DOSBox Staging, SLEEP crashes with SIGSEGV
I only get errors in DOSBox Staging (version 0.78.1), and I have no issues in ordinary DOSBox (version 0.74-3), get no errors there whatsoever.
That you got issues with ordinary DOSBox (version 0.74-3) only adds to my confusion
But that could mean that there might be a bug in DOSBox.
And not to confuse anyone, but I only got problems in "DOSBox Staging".
"DOSBox Staging" is a different form ordinary DOSBox: https://github.com/dosbox-staging/dosbo ... /README.md
I tried running with "cwsdpmi -p" on startup and without. Does not make a difference.
I'll try experimenting with the settings...
Some more info:
I'm on Debian 11 x64
I run DOSBox (APT) and DOSBox Staging (Flatpak) with the default settings.
All I added to both is:
EDIT:
Compiling a single line with "sleep", with -w all -exx gives:
Aborting due to runtime error 12 ("segmentation violation" signal)
That you got issues with ordinary DOSBox (version 0.74-3) only adds to my confusion
But that could mean that there might be a bug in DOSBox.
And not to confuse anyone, but I only got problems in "DOSBox Staging".
"DOSBox Staging" is a different form ordinary DOSBox: https://github.com/dosbox-staging/dosbo ... /README.md
I tried running with "cwsdpmi -p" on startup and without. Does not make a difference.
I'll try experimenting with the settings...
Some more info:
I'm on Debian 11 x64
I run DOSBox (APT) and DOSBox Staging (Flatpak) with the default settings.
All I added to both is:
Code: Select all
[autoexec]
mount c ~/DOS
path=c:\FB
# cwsdpmi -p
Compiling a single line with "sleep", with -w all -exx gives:
Aborting due to runtime error 12 ("segmentation violation" signal)
Re: DOSBox Staging, SLEEP crashes with SIGSEGV
Did some more testing:
gdb gives:
gdb gives:
Program recived signal SIGSEGV, Segmantation fault.
0x000099fb in __dpmi_int ()
Re: DOSBox Staging, SLEEP crashes with SIGSEGV
I've been visiting DOS land in my free time. This particular bug I can reproduce .. sometimes. At first blush it looks like an intermittent bug due to timing and a resultant stack corruption in the setup routines; I don't mean the SLEEP timing itself, but rather the initialization. 'SLEEP 500' will cause the keyboard ISR to be hooked to monitor key presses. As an aside: the logic appears to be that intervals <100 millisecond won't monitor key presses, and intervals >= 100 milliseconds will hook keyboard IRQ 1 and monitor. And side to the aside, DOS is rather flaky especially for debugging fbc & rtlib itself due to long file names. I suspect that DOSBOX itself and other variants don't 100% emulate the real hardware (like masking interrupts, etc), or perhaps the bug exists on real hardware running DOS but the chance of failure is only lower (not eliminated).