You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The SingleApplication constructor explicitly attaches itself to the shared memory and deletes the object QSharedMemory afterwards. This is to make sure that a 'dangling' shared memory which is not referenced anymore (due to a crashed application) is freed in the destructor.
I suggest to check the return value and the possible error when trying to attach, something like
d->memory->attach();
{
switch(d->memory->error())
{
case QSharedMemory::NoError: // successfully attached, resource was already created
d->memory->detach(); // should release the resource
break;
case QSharedMemory::NotFound: // resource is not available yet
break;
default:
abortSafely(); // report error message
}
}
Background: We had the problem that our application didn't start anymore on the build server (Mac). The error message was
SingleApplication: Unable to create block.
SingleApplication: 7 "QSharedMemory::create: out of resources"
which is the message created when d->memory->create( sizeof( InstancesInfo ) ) fails. Unfortunately, we did not check the system resources with ipcs before rebooting the server.
After spending some time in the Qt documentation and the code base, I came to the conclusion that maybe already the attach() failed.
Because the memory itself is not a problem, I assume that the internal QSystemSemaphore of the QSharedMemory could not be acquired.
The text was updated successfully, but these errors were encountered:
We are aware of multiple issues with Qt's latest implementation of QSharedMemory and QSystemSemaphore and even the latter is not truly thread safe. We are working on an implementation that would rely on a different mechanism - QLocalSockets but the development is still in-progress.
The
SingleApplication
constructor explicitly attaches itself to the shared memory and deletes the objectQSharedMemory
afterwards. This is to make sure that a 'dangling' shared memory which is not referenced anymore (due to a crashed application) is freed in the destructor.I suggest to check the return value and the possible error when trying to attach, something like
https://github.com/itay-grudev/SingleApplication/blob/8c48163c4d3fbba603cfe8a5b94046c9dad71825/singleapplication.cpp#L75C25-L75C25
Background: We had the problem that our application didn't start anymore on the build server (Mac). The error message was
which is the message created when
d->memory->create( sizeof( InstancesInfo ) )
fails. Unfortunately, we did not check the system resources withipcs
before rebooting the server.After spending some time in the Qt documentation and the code base, I came to the conclusion that maybe already the
attach()
failed.Because the memory itself is not a problem, I assume that the internal
QSystemSemaphore
of theQSharedMemory
could not be acquired.The text was updated successfully, but these errors were encountered: