Haunting a Windows "Subsurface not start but becoming zombie" bug

Lubomir I. Ivanov neolit123 at gmail.com
Sun Apr 9 05:37:15 PDT 2017


hello,

On 9 April 2017 at 14:09, Stefan Fuchs <sfuchs at gmx.de> wrote:
> Hi All,
>
> I'm trying to haunt another issue I'm seeing already since a long time
> (months):
>
> It is that simply sometimes Subsurface under Windows 10 doesn't start. I
> mean I click on the icon and no window and also no crash info appears. After
> that I have a zombie Subsurface.exe running. I now for the first time
> reproduced this with the MXE debug build and again attached drmingw to the
> zombie exe.
>
> Can s.o. guess s.th. from the output?
>
> What else could I provide to help finding this bug?
>
>

so it appears to be entering an infinite loop when
desktop-widgets/globe.cpp calls setShowScaleBar(true);
it then tries to redirect debug output to a "NullStream" in
MarbleDebug.cpp which appears to fail on Windows.
QDebug attempts to acquire a Mutex lock but fails in
qmutex.cpp::setInternal() (wait()).

i will add a CC to Thiago Macieira to see if he has the time to check
your stack trace.

you could try:
1) in globe.cpp do a on top:
#include "MarbleDebug.h"

then above setShowScaleBar(true); call:
MarbleDebug::setEnabled(false);

2) if the above fails try:
open the Marble source folder and find MarbleDebug.cpp and modify the
contents of the method mDebug() to be like so:
QDebug mDebug()
{
    return qDebug();
}
then rebuild marble.

3) you could also try a different Qt version.

solution 1) is tolerable to be enabled only on Windows on the side of
Subsurface, but ideally the fix should be on the Marble side.

lubomir
--


More information about the subsurface mailing list