0.29.1 Macosx Sonoma - QLog is already running error popup

[jrjesson]

After upgrading to 0.29.1 I now receive an error popup "QLog is already running" when starting QLog. Repro'd on an M1 Macbook Pro , and an M2 Mac Mini. The error does not occur on 0.29.0. I cloned 0.29.1 and built from scratch to confirm the error.

[foldynl]

it is strange because this release does not touch this part of QLog. Unfortunately, I am not able to test it because MacOS build is only prepared by GitHub - I have no MacOS hardware. The only thing that can be wrong is the version of the Qt library, because as I looked, QLog 0.29.1 uses the latest release (6.6), which can be quite problematic.

Please, could you send me the version of Qt that 0.29 is built with (Screenshot of Help->About)? Unfortunately, I don't have access to the build log on GitHub anymore for release 0.29.

[foldynl]

sorry, maybe a useless question, but are you sure that QLog is not really running? Sometimes it happened that QLog was no longer active, but one of the QLOG processes remained active (there was an issue with a Chrome process - QLog's online map).

[jrjesson]

Yes, I was scratching my head about this as well, I did a ps to confirm no running instances, and tested on my two macs. I did a diff on the code between 0.29 and 0.29.1 and no change at all around .AppGuard or main.cpp When I compiled I did just pull QT 6.6 via homebrew to do the build so it could be an issue with that QT release. I'll research to see if I can compile with an older version of QT to confirm. Can you tell me what version of QT you used on 0.29.0?

[foldynl]

That's a question I can't answer. Please try to download the DMG for 0.29.0 from the GitHub Release section, after launch go to Help->About and you will see the Qt version there. Unfortunately, I don't have MacOS HW, so I can't do this - I use the services of GitHub to prepare all DMGs.

I have tested the QLog with Qt6.6 under Windows and there is no issue with the AppGuard. Maybe, it is specific issue for MacOS.

[foldynl]

I extracted the DMG under Linux and it seems that 0.29.0 was prepared based on QT 6.5.2

[foldynl]

Source: https://doc-snapshots.qt.io/qt6-dev/whatsnew66.html#qt-quick-module

The new QNativeIpcKey class holds a native key used by QSharedMemory and QSystemSemaphore, providing better support for sandboxed applications on Apple platforms. See Native IPC Keys for more information.

it seems that something has really changed in QT6.6. Currently, I don't know what exactly this means for our case, but it is obvious that they changed something there.

[foldynl]

Please, could you test the patch above against qt 6.6 (branch bugfix-257)?

[jrjesson]

To your earlier question 0.29.0 used QT 6.5.2. I tested a bit yesterday when I commented out ::isAnotherRunning() the app started and behaved as intended - when I started another instance of the app that second instance exited with "QLog is already running." Pulling the change to test now.

[jrjesson]

I pulled and compiled from your test branch and the popup error still occurs. Curious, I wanted to see what the error result was on the failing call in ::tryToRun
- const bool result = sharedMem.create( sizeof( quint64 ) );.
So I added an fprintf -
// JRJ: print out the error
fprintf(stderr, "\nError = %d %s\n\n", sharedMem.error(), sharedMem.errorString().toLocal8Bit().data() );
The result is the following:

Error = 5 QSharedMemory::attach (shmget): doesn't exist

[jrjesson]

Seeing that prior error, and noting the lack of an .attach() call in the sequence before the create, I added one to the ::tryToRun() method. This seems to fix the issue. I'm not experienced in QT development so am unsure if perhaps QT6.6 made it required to do the .attach() before the .create()?

bool AppGuard::tryToRun(void)
{
FCT_IDENTIFICATION;

if ( isAnotherRunning() )   // Extra check
{
    return false;
}

memLock.acquire();
//JRJ: Add an attach call before the create
sharedMem.attach();
const bool result = sharedMem.create( sizeof( quint64 ) );
memLock.release();
if ( !result )
{
    // JRJ: print out the error
    fprintf(stderr, "\nError = %d %s\n\n", sharedMem.error(), sharedMem.errorString().toLocal8Bit().data() );
    release();
    return false;
}

return true;

}

[foldynl]

it's a mystery why it works. I have tested it on linux and your attach has no negative effect on the function of the class.

Please, could you add qInfo()<< before your attach and test it again? What does it return for the first instance and the second instance of QLog?

if ( isAnotherRunning() )   // Extra check
{
    return false;
}

memLock.acquire();
//JRJ: Add an attach call before the create
qInfo() << sharedMem.attach();
const bool result = sharedMem.create( sizeof( quint64 ) );
memLock.release();
if ( !result )
{
    // JRJ: print out the error
    fprintf(stderr, "\nError = %d %s\n\n", sharedMem.error(), sharedMem.errorString().toLocal8Bit().data() );
    release();
    return false;
}

return true;

[jrjesson]

Ha, this behavior was bugging me so I was reading the docs when you replied. I added qinfo, it returns the following:
10:19:43.908 [INFO ] [0x1da589ec0] [ ] => false [bool AppGuard::tryToRun():core/AppGuard.cpp:109]

That didnt seem completely helpful, so I added another fprintf to get the error and error code - it returned
didAttach 5 QSharedMemory::attach (shmget): doesn't exist

To your earlier point, this feels like a bug in QT 6.6/macosx, the create call is supposed to have an implicit attach, so...

[foldynl]

Many thanks for your assistance. To understand this, we would have to dive into QT source code....OK... I'll add the extra attach with a note that this is a hack for QT6.6. In the meantime, I have tested it on other platforms and QT versions and it has no impact no function. So it is not necessary to add an extra compilation condition there.

I will try to publish it as a fix, but unfortunately I don't have time to do it today. I will try to create a new release tomorrow, so the fixed DMG could be available tomorrow.

[jrjesson]

No worries on timing, I have my build :-) I did send an email based on your github profile for any future followups.