Your title is ambiguous. The way you've worded it assumes that DOSBox is at fault while in truth you're feeding it a bum file. Maybe DOSBox's error trapping could be better but the reality is that some apps will crash when being given incorrect config data.

Well dosbox should put out an error message for that, at least that's what
i'd assume it to do (and it maybe did somewhen.....)

I get this every day as a tester.

The question wether an application should out an error or the user should know that the file used contains an errors and thus should expect errors is up to the answer on the question how far do the analysts/developers want to go in making their application error/dumb proof.

And I concurr with wd.

Erik.

dh4rm4: An application crashes is always a bug. This has nothing to do with what data it is being fed. An application must always gracefully cope with malformed input. After all, it is being used by the nr. 1 source of garbage input, humans.

There's one major point where i don't agree that being bug-free is the top goal:
when it affects performance very badly. There are lots of cases in dosbox where
you could go for correctness, but it simply isn't feasible.
But imgmount surely isn't such a case, so hoping to find some time to get into this 😉

Well, a crash is performance relevant: it can kill all data (game state, whatever) you have created in that session so far. All performance doesn't help if at the end that, which was "created" by that performance is lost.
(Example (not DOSBox but a game itself, that crashes): the totally annoying crashes I get in Alien Legacy that negated hours of gameplay...)

Not implementing features is perfectly valid, of course, but in no case should dosbox itself crash. Note that I don't consider "E_Exit" a crash. It is an unrecoverable(!) error that is cleanly handled, even though it might look like a crash, and even though it is not the most user-friendly action.

the totally annoying crashes I get in Alien Legacy

Dunno about that, sounds like a "regular" bug. Was more thinking of
for example that game Greedy (writing over pmode segment limits
and requiring pagefaults to bank-switch during drawing routines).

Oops sorry. Should read the whole post first.

The question wether an application should out an error or the user should know that the file used contains an errors and thus should expect errors is up to the answer on the question how far do the analysts/developers want to go in making their application error/dumb proof.

Seems the answer is a tough nut to crack?
For me it would come down to priorities and these differ from person to person.

Erik.

Is this reproducable with the .cue file only? I only get nice error messages,
but never anything close to a crash.

wd wrote:

I only get nice error messages,
but never anything close to a crash.

Same here. I've created plenty of bin/cue images of DOS games to use in DOSBox and in a "worst case scenario", when I tried loading it through the CUE file, DOSBox just gave me a simple message (in the command line) that it couldn't load the image due to some unspecified error (can't remember the exact message).

In fact, DOSBox detects a faulty (bin/cue) image far better than most Windows applications. I had a few cases that UltraISO/Alcohol/etc would load up the image just fine and only in DOSBox some small errors/faults got detected.

By reviewing the image creation process (sometimes trying another app), the problem was solved and DOSBox loaded the bin/cue just fine.

So ErikGG, either the CD/game has some tricky protection scheme that DOSBox can't (easily) handle (hope it's not another FIFA), or you just created a faulty image. Maybe someone else has the game and could also verify this?

The crash can be generated using the attached cue file.

I also added the conf file used to start DOSBox.

DOSBox 0.72 was used.

In Windows XP : Can we fix this dialog.
In Windows 2K : AV-error referencing to a null pointer.

Edit : Just found out that DOSBox doesn't crash if you keep only the mount of the cue file.

Erik.

ErikGG wrote:

Edit : Just found out that DOSBox doesn't crash if you keep only the mount of the cue file.

When using a BIN/CUE pair (I'm refering within DOSBox, but also applies to the actual OS), one is "supposed" to mount directly the CUE file, as it points to the BIN image (in this case, also manages the use of the audio tracks).

What is the actual message you get by mounting the CUE?

Also, have you tried creating the image through another program? And does changing the mounting parameter " -t iso " to " -t cdrom " makes any difference?

Oh, and I've sometimes had problems loading this type of images in long paths, especially the ones likes "documents and settings" that are converted to 8 charactes inside DOSBox.

And does changing the mounting parameter " -t iso " to " -t cdrom " makes any difference?

Don't bother. It is identical. ( I added -t cdrom as I always typed it instead of iso.)

Here is the code:

1if(type == "cdrom") type = "iso"; //Tiny hack for people who like to type -t cdrom

No hidden magic.

Thank you for clarifying that for me, Qbix!

That's the joy of this forum... Almost everyday I keep learning new things. 😀

*** EDIT ***

Qbix, could what I mentioned above about mounting images stored in long paths (and directories with converted names - more than 8 chars) be causing this? It has happened in the past and the only workaround was changing the file path (can't remember if I changed the image name itself, as it also happened with images with converted names).

njaydg thanks for the help but I'm not having any trouble mounting the image...

After checking the cue file again, I found that ISOBuster had created a cue file not "linked" to the bin file. Code: FILE "CD.bi […]
Show full quote

After checking the cue file again, I found that ISOBuster had created a cue file not "linked" to the bin file.
Code:
FILE "CD.bin" BINARY
While the bin file was called "track1.bin".
Changing the CD.bin to 1_trackk1.bin fixed it.

I only found that using DOSBox 0.72, starting it with the conf file posted above, together with the above cue file, makes it crash with and Acces Violation referencing a null pointer.

Is this reproducable on other systems?

Erik.

njaydg wrote:

Qbix, could what I mentioned above about mounting images stored in long paths (and directories with converted names - more than 8 chars) be causing this?

I don't think so. The problem there is with the command line buffer being of limited length, so the (img)mount command only sees a partial mount specification.

ErikGG wrote:

Is this reproducable on other systems?

I will give it a try.

Yes, I've seen these crashes, but never been able to reproduce them. But it also happens with Erik's cue file

1Program received signal SIGSEGV, Segmentation fault.
20x00000000 in ?? ()
3(gdb) bt
4#0  0x00000000 in ?? ()
5#1  0x0046c243 in CDROM_Interface_Image::GetRealFileName(std::string&, std::string&) (this=0xa409958, filename=@0x22aeb0, pathname=@0x22b2b0)
6    at cdrom_image.cpp:608
7#2  0x0046e683 in CDROM_Interface_Image::LoadCueSheet(char*) (this=0xa409958, 
8    cuefile=0xa409904 "1_trackk1.cue ") at cdrom_image.cpp:484
9#3  0x0046f56d in CDROM_Interface_Image::SetDevice(char*, int) (
10    this=0xa409958, path=0xa409904 "1_trackk1.cue ", forceCD=-1)
11    at cdrom_image.cpp:165
12#4  0x00470f24 in CMscdex::AddDrive(unsigned short, char*, unsigned char&) (
13    this=0xa3fae40, _drive=3, physicalPath=0xa409904 "1_trackk1.cue ", 
14    subUnit=@0xb3aa7c1) at dos_mscdex.cpp:305
15#5  0x00473350 in MSCDEX_AddDrive(char, char const*, unsigned char&) (
16    driveLetter=68, physicalPath=0xa409904 "1_trackk1.cue ", 
17    subUnit=@0xb3aa7c1) at dos_mscdex.cpp:1215
18#6  0x0048aada in isoDrive::UpdateMscdex(char, char const*, unsigned char&) (
19    this=0xb370048, driveLetter=68 'D', path=0xa409904 "1_trackk1.cue ", 
20    subUnit=@0xb3aa7c1) at drive_iso.cpp:234
21#7  0x0048b640 in isoDrive::isoDrive(char, char const*, unsigned char, int&) (
22    this=0xb370048, driveLetter=68 'D', fileName=0xa409904 "1_trackk1.cue ", 
23    mediaid=248, error=@0x22bf08) at drive_iso.cpp:154
24#8  0x006525ef in IMGMOUNT::Run() (this=0xa409778)

Confirmed. Crashes 0.65, 70, 71, 72 and a recent CVS version.