D14606: KCrash: DrKonqi cancelled = able to start...

René J.V. Bertin noreply at phabricator.kde.org
Sun Aug 5 19:06:00 BST 2018


rjvbb added a comment.


  Actually, it's even worse than that: I didn't double-check my assumptions about the use of DrKonqi's return/exit code. Looking at the code again there is actually no way that information is even obtained. The `startProcess` function simply starts DrKonqi and then waits for it to exit if so instructed; the only information obtained about the crashreporter is its PID.
  
  And indeed, DrKonqi exits with 0 for me too when I cancel/close it.
  
  In a way this is worse not just because my brain was cooked yesterday. It means we're getting different behaviour inside KCrash: the value of `crashRecursionCounter`. And I'm back to not understanding how that's possible. I don't see how `crashRecursionCounter` could ever be `>2` unless you attempt to restart the crashed application. But that also doesn't work for me: it starts a new application = new PID = `crashRecursionCounter` never increases.
  
  That counter gets set to 2 here:
  
    if (crashRecursionCounter < 2) {
        if (s_emergencySaveFunction) {
            s_emergencySaveFunction(sig);
        }
        if ((s_flags & AutoRestart) && s_autoRestartCommand) {
            QThread::sleep(1);
            startProcess(s_autoRestartArgc, const_cast<const char **>(s_autoRestartCommandLine), false);
        }
        crashRecursionCounter++;
    }
  
  A bit strange that the counter would always be increased and not only when there has been an auto-restart attempt, but let's ignore that for now.
  
  I see no other places where the counter is increased, so apparently the code assumes that the function itself can be called multiple times. But how? I see only 2 possibilities:
  
  - When the application receives an additional signal that is connected to the `defaultCrashHandler()` function
  - When the application is restarted without changing its PID and without re-initialising all its static variables - is that even possible (after a fatal exception)?
  
  In other words, how do you get the `crashRecursionCounter >= 4` required for not printing the unable-to-start warning?
  
  Answer: you never get to that check:
  
    if (!s_coreConfig->isProcess()) {
        // Only exit if we don't forward to core dumps
        _exit(253);
    }
  
  On my system:
  
    %> cat /proc/sys/kernel/core_pattern
    |/usr/share/apport/apport %p %s %c %P
  
  Q.E.D. ...

REPOSITORY
  R285 KCrash

REVISION DETAIL
  https://phabricator.kde.org/D14606

To: rjvbb, #frameworks, sitter
Cc: dfaure, kde-frameworks-devel, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180805/0a96ed58/attachment.html>


More information about the Kde-frameworks-devel mailing list