On 9 April 2017 at 17:33, Stefan Fuchs <[email protected]> wrote:
> Hi Lubomir,
>
> thanks for looking into this!
>
>
> Am 09.04.2017 um 14:37 schrieb Lubomir I. Ivanov:
>
> 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.
>
> 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);
>
> This variant 1) does build.
> Then when running it under Windows 10 it does show a similar behaviour: It
> starts 95% of the times but again sometimes I end up with a zombie process.
> I again attached drmingw. Result is attached to this mail. From what I can
> see still marble is involved.
>
in practice, things like the "runs 95% of time" are complicated to debug.
for now you can try commenting out this line in globe.cpp:
setMapThemeId("earth/googlesat/googlesat.dgml");
but this disables the Marble theme.
we do have reports by Windows 10 users about Marble issues:
https://github.com/Subsurface-divelog/subsurface/issues/169
which may hint about a generic Windows 10 / Marble problem, of sorts.
the thing is, your reports point towards Qt methods which is troubling.
lubomir
--
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
