DOSBox SVN r3869 - Screen cap causes crash

[exofreeze]

Hitting ctrl-f5 within the latest SVN build posted at EmuCR (DOSBox SVN r3869) causes the program to go non-responsive, Necessitating a force close to return to the desktop.

I have tested it from the prompt as well as within 4 different games.

[truth_deleted]

That's not an official version and it is unknown whether they built it correctly. It's reasonable to verify the issue against the official version of dosbox or one that you compile from SVN.

[Dominus]

See http://www.dosbox.com/wiki/SVN_Builds the emucr build is without screenshot function

[exofreeze]

Is there another source for SVN builds that do have this function?

I'm not entirely keen on spending an afternoon learning how to compile it.

Last time I did that was with mame and it was a real PITA (even following step by step instructions) for someone who didn't have all the tools all downloaded and ready to go.

Thanks

[bloodbat]

Probably Daum, and mine, of the 2nd one I'm sure.

[Mok]

Sorry for necroing this old thread, but this bug is still in the latest SVN version. As far as I was able to check, the problem is with Dosbox not setting/clearing all needed fields in png_text structure and this causes random crashes. Small change that (so far) fixed it for me:

Code: Select all

--- old/src/hardware/hardware.cpp   2017-05-30 13:35:08.000000000 +0200
+++ new/src/hardware/hardware.cpp   2017-06-18 17:07:23.236694300 +0200
@@ -361,7 +361,7 @@
       }
 #ifdef PNG_TEXT_SUPPORTED
       int fields = 1;
-      png_text text[1];
+      png_text text[1] = {};
       const char* text_s = "DOSBox " VERSION;
       size_t strl = strlen(text_s);
       char* ptext_s = new char[strl + 1];

[Qbix]

Weird. We are using it identical to
http://www.libpng.org/pub/png/book/chapter15.html

It might depend on the libpng version used, as it doesn't crash at my place...

[Mok]

You are probably right. I used latest libpng. Their example code in example.c is setting it like this:

Code: Select all

      char key0[]="Title";
      char text0[]="Mona Lisa";
      text_ptr[0].key = key0;
      text_ptr[0].text = text0;
      text_ptr[0].compression = PNG_TEXT_COMPRESSION_NONE;
      text_ptr[0].itxt_length = 0;
      text_ptr[0].lang = NULL;
      text_ptr[0].lang_key = NULL;


I compiled dosbox using VC Express 2015 for Desktop. But I remember getting the same problem years ago and I always disabled screenshots when compiling Dosbox since that time (as I usually don't need them).

[Qbix]

right, so there are more fields....
I use a different compiler, so that might influence things as well (which data ends up in the uninitialized fields).
Nonetheless, thanks for getting to the bottom of it.

[Mok]

Unfortunately that change was not enough. Possibly it only masked the real problem (so maybe revert it). I updated some files (libpng too) and after recompile the crash is back. Sigh... I'd trace it but Dosbox creates some thread that (after stopping emulation) eats up all cpu making it impossible to debug here, ie. I launch dosbox.exe under ollydbg, put a breakpoint at "creating screenshot" log and when it reaches the place, the system is taking around 5 seconds to respond to a keypress or mouse move. I have to forcefully kill the task to get it back to normal. Sorry about the noise.

Edit: I tried to find the reason for crash but failed. Somehow the problem seems to related to when the capture code is executed (inside render thread). When I modified the code to write the same line for the whole image, it passes and png file is written correctly. When I wrote first 100 lines and the rest the same one, it passed again. But attempting to write say 200 lines resulted in crash (regardless which lines were written). It's like png compression is taking too long and somehow that messes the rest of the code. Oh well, will try to switch back to mingw32 compiler and see if it's better there.

[Mok]

I figured it out. My mistake but current Dosbox requires that libpng is either statically linked or it's using exactly the same C runtime. Unfortunately on Windows with dozens of different runtimes, you may want to compile a version that does not require downloading some specific C runtime to run and you get into problems. Below is example patch that fixes it. If you compile some "custom build" and screenshot is crashing, apply and it will probably go away (it's unlikely it will get applied as it's windows specific and happens only if you do not use default compile options). It doesn't fix crash on Video capture, but it's a start

Code: Select all

--- old/hardware.cpp   2017-06-19 11:09:59.000000000 +0200
+++ new/hardware.cpp   2017-06-29 23:41:19.855780300 +0200
@@ -298,6 +298,22 @@
 }
 #endif
 
+#if (C_SSHOT)
+void our_write(png_structp png_ptr, png_bytep data, png_size_t length) {
+   png_size_t check;
+
+   check = fwrite(data, 1, length, (png_FILE_p)png_get_io_ptr(png_ptr));
+
+   if (check != length)
+   {
+      png_error(png_ptr, "Write Error");
+   }
+}
+
+void our_flush(png_structp png_ptr) {
+}
+#endif
+
 void CAPTURE_AddImage(Bitu width, Bitu height, Bitu bpp, Bitu pitch, Bitu flags, float fps, Bit8u * data, Bit8u * pal) {
 #if (C_SSHOT)
    Bitu i;
@@ -333,7 +349,7 @@
       }
    
       /* Finalize the initing of png library */
-      png_init_io(png_ptr, fp);
+      png_set_write_fn(png_ptr, (png_voidp)fp, our_write, our_flush);
       png_set_compression_level(png_ptr,Z_BEST_COMPRESSION);
       
       /* set other zlib parameters */


[zirkoni]

It doesn't fix crash on Video capture, but it's a start

Old thread but I'll post this here because it's in the Google seach results for this issue...

The video capture crash is probably caused by a new version of libpng.
At some point libpng added the definition of Z_SOLO to it's Visual Studio zlib project. This causes DOSBox to crash when trying to record a video (zmbv.cpp VideoCodec::SetupCompress fails because of Z_STREAM_ERROR).

The issue is easily fixed by removing the Z_SOLO definition from the zlib project and compiling zlib, libpng and DOSBox again. Z_SOLO seems to have something to do with embedded devices that don't have all the necessary external libraries for normal build so I'm not sure why it's defined in a Win32 project (and if you build zlib & libpng using the MinGW environment, Z_SOLO is not defined by default). After removing Z_SOLO screen recording worked with the latest versions of zlib and libpng, all compiled with Visual Studio 2015.

[rainwarrior]

I get a crash every time I try to screen capture in r4130.

If this is at all useful: Unhandled exception at 0x77E8EBCB (ntdll.dll) in dosbox.exe: 0xC0000005: Access violation writing location 0x00000014.


Edit: Oh, please excuse that, I didn't realize that the EmuCR build is not "official"? ...and it has no screenshot function. ? That's very odd, but at least that's an explanation. Strangely, the note on the wiki also says video capture is not available, but it appears to work perfectly? (I'm not going to try to guess what the reasons for these things are, but I would say that crashing on use of an unsupported feature instead of it just not working or displaying a message to that effect made it more than a little frustrating to try and understand, for me.)

Is there any other more "official" SVN build available besides EmuCR? All the other ones linked in the wiki seem to have strange additions (DOSBox-X, etc.)

[Yesterplay80]

The "strange additions", as you call them, mean those builds have actually some nice improvements and features added to the original source code of DOSBox. So trying one of those or DOSBBox ECE (see signature) might even be a pleasant surprise. If you just want to use a version based on the latest original code, you can find one on my blog as well.