johngehrig added a comment.
Sorry for the delay... I was finally able to get the crashing machine set up
again.
Yes, it looks like the descuctor for `job` was called while the KMessageBox
was in the process of being painted onscreen (breakpoint in
kauthexecutejob.cpp).
I tried maki
johngehrig updated this revision to Diff 57581.
johngehrig edited the summary of this revision.
johngehrig edited the test plan for this revision.
johngehrig added a comment.
Ordering changed, qWarning first.
job->errorString() displayed for all values of job->error().
A QString object was
johngehrig added a comment.
Thanks for the clarification! I understand what you are saying :)
I see errorString() has a fallback path stating the app is broken for invalid
errror() values. Agreed, this isn't right...
Yes, setting a breakpoint at the destructor for job was my plan. I
johngehrig added a comment.
The API for `errorString()` calls out that it should not be called when
`error() == 0`. The code does not explicitly check for this scenario.
Somehow users (myself and others) can get into a state where `!rc && error()
== 0`, and we are calling `errorString()`
johngehrig added a comment.
@anthonyfieroni Yes, I think there also an issue with KAuth here. This
machine never gets to the auth prompt, which works fine on another machine.
I don't think "jobs" is deleting itself, otherwise we would segfault on
"jobs->error()". No?
@davidedmundson
johngehrig added a comment.
It looks like my alternate error "unknown error" isn't showing up in the
dialog... So this isn't quite right yet.
I will fix this together with any other feedback. The segfault does appears
to be resolved.
REPOSITORY
R123 SDDM Configuration Panel (KCM)
REV
