mythfrontend exits with status one before gui appears

[Roger James]

Using mythbuntu 16.04 with mythfrontend configured to run via .config/autostart when the gui desktop boots. Randomly mythfrontend exits before any gui is displayed. Because the shell exit status is one (process exit 0x100) the mythfrontend wrapper script does not try to restart. This appears to be some kind of race condition in the start up environment. Putting a 60 second sleep in the wrapper script appears to cure it.

It appears that mythfrontend main.cpp is getting as far as launching the housekeeper but is exiting before the gui is drawn by the message loop.

Has anyone else seen this?

Roger

[Roger James (rogerjames99)]

I got the exit codes mixed up in the original report. I used a modified version of last one to print out the exit codes. Unfortunately it does not report full programme names, both the wrapper and mythfrontend.real show as mythfrontend!

[Roger James (rogerjames99)]

I wish this thing did not have autocorrect. I meant to say lastcomm.

[Roger James (rogerjames99)]

I seem to be having a dialogue with myself here. However, this bug seems very time critical. If I turn on too much verbose debugging, it goes away. If I run it via gdb, it goes away. If I run it with strace, it goes away. I moved the shuttle box it was running on, up to my workbench, it went away. The only difference in the last case I could think of was on my workbench it was connected to the same switch the back end was connected to, when it is sat next to the TV it goes through another mini switch first.

I am baffled by this and it very hard to debug. Any ideas anyone.

Roger

[Roger James (rogerjames99)]

I have now narrowed this down to a sigsegv in Qt code called from here in mythimage.cpp

bool MythImage::Load(const QString &filename)
{
    if (filename.isEmpty())
        return false;

    QImage *im = NULL;

***** if (filename.startsWith("myth://")) ******

This is reproducible but the large number of threads running at this time in the start up sequence (parallel loading of loads of theme images), make hard to analyse exactly what is going on.

If anyone knows any easy ways of finding the actual data in QDataArrays in GDB please let me know.

Roger

[Roger James (rogerjames99)]

Ask far as I can see the crash itself is a duplicate of bug #1016173. The fact that the SIGSEGV is caught by the app and converted to an exit code 1 is separate issue involving both the mythfrontend(.real) programme and the mythfrontend wrapper script. As things are at the moment users will be left with a desktop showing and no evidence in the logs of what happened. The crash in QFactoryLoader::Instance appears to be related to a qt image loader plugin being unloaded whilst a thread is still using it. It occurs at startup because all the pool threads are being used to load theme images.

I intend to raise an upstream bug for this and a new bug here for the wrapper problem/feature. I will close this bug as a duplicate.

Roger

[Roger James (rogerjames99)]

Raised as buf #12909 on mythtv.org