MSVC Dynamic/Debug build crashes

[dannyedel]

Using the prebuilt dependencies from #147, building in Debug mode results in a Stack Overflow.

Current Working Theory:

A library in release mode new'd the pointer, but we delete it in Debug mode, triggering the "Was this memory block alloc'd with (debug) new" and the double-free check, which both fail since the memory block was never put into the list.

---

Debug this and spawn a new PR that enables AppVeyor to test both Debug and Release mode.

[dannyedel]

@projekter this batch script reproduces the "Stack overflow" crash for me.

https://gist.github.com/dannyedel/9bdbcb2e44e568ba1c39

Win7 VM state before running script:

• Install MSVC 2013 (a.k.a. version 12.0) Community update 5
• Install boost 1.60 msvc 12.0 32 bit
• Install qt 5.5.1 msvc2013 32 bit
• Install cmake 3.4.0 (added to path)
• Install git for windows 2.7.1.2 32 bit (only git added to path, not rest of utils)
• Install 7zip 1514
• Unpack DependenciesDyn.rar directly to C:\

I called the batch script from inside a "Git CMD", and I use virtualbox's "Shared folders" feature to access my dspdfviewer source as \\vboxsrv\dspdfviewer. A native git checkout somewhere should work too, it's just convenient for me to directly edit my host's directory, since I can throw away and remake the VM whenever I feel like it.

While I'm trying to debug this, can you check whether it also crashes on your system? If it does, it may not be a problem about a DLL missing in the package, but maybe one thing never got built in debug mode.

[dannyedel]

I had a lengthy answer ready and then the power went out. Serisouly. (Note to self: Save money for UPSs also on the workstation, not just the homeserver)

Short story:

• CMake correctly passes the …d.lib argument to MSVC's link.exe.
• When I load the binary into MSVC and check Debug -> Windows -> Modules (Ctrl+Alt+U) it lists the …d.dll for the Qt stuff, but not for the precompiled dependencies.
• The …d.lib files don't seem to contain references to the …d.dll files, but rather to the "normal" non-d files:

strings dspdf/popplerDyn/poppler/lib/poppler-qt5d.lib \
    | grep --only-matching -w .*.dll | sort -u
#output:
poppler-qt5.dll

This looks different than on a Qt5 .lib file:

strings Qt5Cored.lib  | grep --only-matching -w .*.dll | sort -u
#output:
Qt5Cored.dll

@projekter can you check whether the .lib files are supposed to do that?

---

Loaded modules on testrunner.exe:

Checking the "Order" column, Qt5Guid.dll is loaded really early (by testrunner itself), and poppler-qt5.dll is number 24, then Qt5Gui.dll (non-debug version) is loaded as number 25. That would explain why QImage's allocated from within poppler (using Qt5Gui non-debug allocator) but destroyed in testrunner (using Qt5Gui Debug deallocator) cause the crash.

[projekter]

Yes, that's exactly what they are supposed to do. Sorry for this, I should have mentioned it: The applications normally do not have separate libaries, depending on whether they are debug or release compiled. If you want to use the debug libraries, you have to copy them to the application folder and remove the "d" from the filename. That's the only way to enforce their usage.

[dannyedel]

Thanks for the quick answer!

Trying that now :+1:

[dannyedel]

Now it works.

It turns out, copying the debug poppler-qt5d.dll is enough to solve the problem at hand, since now no more library seems to be double-loaded. I'm not sure if I'm in the realm of undefined behaviour here, but now the testsuite walks through without erros and I can call Debug\dspdfviewer.exe and use it.

For reference: Module List now

---

revised batch script:

https://gist.github.com/dannyedel/549e57aa73936d7d7a7f

---

@projekter does that look OK to you? If yes, I'd implement this on appveyor and then close this ticket.

[projekter]

Compiles and runs all tests without any complaints.