Velvet Studio 2.01 causes a crash (immediate exit, no hang) during start-up

teimoso commented 6 years ago

_{DOSBox-X Version 0.82.6 (non-MinGW) and BETA 2018-05-18 (non-MinGW)
DOSBox-X Configuration stock? (I don't know where DOSBox-X's configuration is stored; settings appear to be default)
Operating System Windows 7 (64-bit; Home Premium)
Processor Intel Core i7 Q 720 (1.6 GHz)}

Exposition

This crash does not occur in DOSBox SVN r4106 or DOSBox ECE r4106. Velvet Studio is a tracker (music tool) for DOS. Download available at pouët.net. Source code available at GitHub.

Description

Velvet Studio 2.01 crashes shortly after starting (executing VS.EXE). The program's "fade-in" effect can be seen before DOSBox-X immediately exits. The crash seems to be independent of the program's configuration file (VS.CFG).

Reproduction

mount a directory containing the Velvet Studio 2.01 files
Start VS.EXE

If this issue isn't on my end, DOSBox-X should crash very quickly.

Extra

Output from the console is as follows: _{ver: BETA 2018-05-18 (non-MinGW)}

LOG: EMS page frame at 0xe000-0xefff
LOG: COMMAND.COM env size:             720 bytes
LOG: COMMAND.COM environment block:    0x0801 sz=0x002d
LOG: COMMAND.COM main body (PSP):      0x082f sz=0x009a
LOG: COMMAND.COM stack:                0x0849
LOG: pixratio 1.334, dw false, dh false
LOG: SDL menuBox w=720 h=17
LOG:   21070232 ERROR DOSMISC:DOS:INT 2F Unhandled call AX=1687
LOG: DOSBox switched to max cycles, because of the setting: cycles=auto. If the game runs too fast try a fixed cycles amount in DOSBox's options.
LOG:   21072541 ERROR DOSMISC:DOS:INT 2F Unhandled call AX=1687
LOG:   33702404 ERROR DOSMISC:DOS:INT 2F Unhandled call AX=1500
LOG: pixratio 1.000, dw false, dh false
LOG: SDL menuBox w=640 h=17

VS.EXE is started just before the first error occurs (line starting with LOG: 21070232 ERROR...) Since I have no idea how to access any log files for DOSBox-X, I attempted to screenshot the console window as late as possible before the crash. This log might not be satisfactory as a result; please let me know if better logging methods are available.

joncampbell123 commented 6 years ago

add a [log] section to dosbox.conf, specify a log file, and run dosbox-x with --debug.

The FTP link on Pouet doesn't work.

teimoso commented 6 years ago

Sorry, I should've checked the link; the domain providing it isn't usually down. The archive.org Wayback Machine seems to have a copy. Log file: log.txt

joncampbell123 commented 6 years ago

"E_Exit: INT:Gate Selector points to illegal descriptor with type 0"

joncampbell123 commented 6 years ago

It doesn't crash if you add this to your dosbox.conf

[gus]
gus=true

It seems to be a problem with lack of GUS, or it's Sound Blaster support.

EDIT: Selecting Sound Blaster support manually with /f causes the crash.

teimoso commented 6 years ago

Velvet Studio has options for the sound card output:

Nosound
GUS
SB PRO
SB 16
SB
GUSMAX

These can be accessed by clicking the CONFIG drop-down menu at the top of the screen, followed by Configure SoundCard...

On to the issue, using SB 16 output with gus=true still gets me a crash (a hang, not instant exit).

with SB 16 sound card output Interestingly, with just gus=true (no ULTRADIR), starting VS.EXE caused DOSBox-X to restart itself. After the restart, a second attempt caused a crash (in the form of a hang, not a plain exit). I am able to reproduce this consistently. Is this normal behavior? After providing an ULTRADIR, DOSBox-X crashes as it did previously (same E_Exit message at the end).

with GUS sound card output

with an `ULTRADIR`

Velvet Studio successfully starts In this case, maybe my problem was my VS.CFG. I was able to successfully start Velvet Studio in DOSBox-X by changing the Velvet Studio soundcard output to Nosound through another version of DOSBox. After the change, the option was automatically changed to GUS.
Crashes with WAV samples (and microphone usage?) Loading a WAV sample or a project (AMS file) with samples causes a crash, as does the SAMPLE option in the sample editor (which uses the microphone to record a sample).
Audio output works(?) with panning I was able to draw a sample and get some output (in the form of clicks; looping the sample didn't work). A Panpot option in the sample editor did move the click around my left and right ears.
without an ULTRADIR
Velvet Studio successfully starts
Crashes with 'WAV' samples (and microphone usage?) I got the same result as SB 16 output without ULTRADIR. After loading a sample, DOSBox-X automatically restarted. Loading VS.EXE again resulted in a hang before the program could display any graphics.

GUSMAX output just switches me back to GUS.

Log file without ULTRADIR: log.txt (lots of ERROR CPU:Write [x] to rom at [yyyyyy]) Log file with ULTRADIR: log.txt Log file with ULTRADIR after loading a project with samples: log.txt (E_Exit: RET from illegal descriptor type 14)

It's late at night (for me); if you're willing to debug more, a Velvet Studio project and a couple of WAV samples are attached. testfile.tar.gz _{(sorry, GitHub won't let me attach ZIP files)}

joncampbell123 commented 6 years ago

If you do "LOADFIX" before running VS.EXE, the crash does not occur.

Once again, there is this strange problem with loading EXE files at around segment 800h.

joncampbell123 commented 6 years ago

And of course, using "minimum mcb segment" and "minimum mcb free" to load it LOWER in memory also resolves the crash.

teimoso commented 6 years ago

I also get no crashes when I run LOADFIX before VS.EXE. Both SB 16 and GUS output modes load and play samples/projects properly, and gus=true is no longer needed to prevent a crash. Is it some sort of memory issue?

joncampbell123 commented 6 years ago

There seems to be a consistent issue with DOS games crashing when loaded at about 32KB from the bottom of memory (about segment 800h) that I'm not certain about. Loading things higher OR lower seems to solve crashes. I have no idea why, yet.

teimoso commented 6 years ago

A couple of other trackers (FastTracker II, Impulse Tracker) work fine without LOADFIX, so I guess those don't load into the offending memory area. You've probably already looked into it, but maybe the memory around there is corrupt or uninitialized?

joncampbell123 commented 6 years ago

I just spent 2 and a half hours looking into the mystery memory corruption, and.... I'm still stumped.

joncampbell123 commented 6 years ago

However I have figured out that the specific crash is something that causes VS.EXE to jump to a NULL segment, triggering a General Protection Fault that faults into itself repeatedly until the stack overruns the IDT with zeros and causes the error.

ghost commented 6 years ago

The cause of dreaded low segment issue requiring loadfix or no HMA is known to be segment register underflow / address overflow usage. Normally (without HMA) address space will wrap-around and operations will still do stuff right from segments Fxxx plus overflowing address, but with HMA it will overwrite HMA area instead, where DOS(box) data resides.

0x800 probably relates to how much they underflow (segment 0x800 gives address 0x8000, and it's the max negative value with signed 16-bit int, I suspect signed ints are probably used for offset calculation) and where resulting writes hit (start of the HMA area probably).

joncampbell123 / dosbox-x