-
-
Notifications
You must be signed in to change notification settings - Fork 222
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: Failed to create instance #202
base: master
Are you sure you want to change the base?
Conversation
Sometimes Ubuntu20.04-24.04 execution of `d->memory->attach()` crashes here and prints the necessary information to determine that the creation has failed
@@ -72,8 +72,9 @@ SingleApplication::SingleApplication( int &argc, char *argv[], bool allowSeconda | |||
#else | |||
d->memory = new QSharedMemory( d->blockServerName ); | |||
#endif | |||
d->memory->attach(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When debugging and releasing, there is a high probability that this line will crash after a few more tries;
Being able to see that d->memory->attach(): true
Shared memory creation failed: "QSharedMemory::attach (shm_open): already exists"
Successfully attached to existing shared memory block
Memory block successfully locked
Shared memory data doesn't NULL!
Primary: true "0x1" ← see
Secondary: 0 "0x0" ← see
Primary PID: 9425 "0x24D1"
Checksum: 5070 "0x13CE"
Primary User: vincent Just skipped the associated judgment and final execution exit |
bool ok = d->memory->attach(); | ||
qCritical() << "d->memory->attach():" << ok; | ||
if (ok) delete d->memory; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That first attach
and delete
are dummy operations. They are only there as I noticed that when there is orphaned shared memory after the original process has crashed, attaching and deleting clears it up. If it's not orphaned this is a no-op.
As such I didn't think I need to check their success status.
@@ -91,23 +92,46 @@ SingleApplication::SingleApplication( int &argc, char *argv[], bool allowSeconda | |||
} | |||
d->initializeMemoryBlock(); | |||
} else { | |||
|
|||
qCritical() << "Shared memory creation failed:" << d->memory->errorString(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a valid code path when there is already an instance running. There is no need for qCritical
here.
Why? Why do you want all these unnecessary and misleading |
When the creation fails (constructor), nothing logs neither prints. It can be very confusing. An example process is shown in the video at #201 |
Sometimes Ubuntu20.04-24.04 execution of
d->memory->attach()
crashes here and prints the necessary information to determine that the creation has failed