Summary: | improve network io debug output when bugzilla submission fails | ||
---|---|---|---|
Product: | [Applications] drkonqi | Reporter: | stephan.laenge |
Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | REPORTED --- | ||
Severity: | normal | CC: | sitter |
Priority: | NOR | ||
Version: | 6.1.5 | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
See Also: |
https://bugs.kde.org/show_bug.cgi?id=493314 https://bugs.kde.org/show_bug.cgi?id=461340 https://bugs.kde.org/show_bug.cgi?id=494041 |
||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | Section from journalctl |
Description
stephan.laenge
2024-09-27 22:30:58 UTC
There is logic that removes the trace when it is too long. How did you manage to exhaust 65535 with your comment? > There is logic that removes the trace when it is too long. How did you manage to exhaust 65535 with your comment? Actually, you are right (and i was wrong)! I just made plasmashell crash and generated a 84k character crash report. It was sent without problems, and the stackTrace was added as attachment, just as i had suggested should be done. The resulting bug report is here: https://bugs.kde.org/show_bug.cgi?id=494041 I did this by doing what i described here: https://bugs.kde.org/show_bug.cgi?id=493314#c4 This means that the 64k character limit is not the problem. Me not having internet was also not the problem, because i could open https://bugs.kde.org/rest/bug?token=REDACTED in Firefox, which was a link provided by DrKonqi in the error message. And this maybe also means the bug reporting system was not down either? So at the moment i don't know what could be wrong. If i produce a few crashes and test if they can be reported i will just spam the bug report system (and maybe get banned or so). And even if i could somehow reproduce the problem, it's not like DrKonqi crashes, so how would i know what's wrong? Maybe you or i will come up with a idea how to reproduce this. If not, i guess now that it's not a character limit it's not going to be a big problem if the bug remains. > How did you manage to exhaust 65535 with your comment?
After sending the bug report failed, I saved it and tried to add it to the corresponding bug report as a comment.
I guess an action item to derive is to improve the debug output when things go wrong. I am not sure we can, but needs looking into. Turns out according to the code the somethingsomething would have been the important bit. Unfortunately i did not save or screenshot the error message. The "Failed to submit bug report: Error transferring" is just what i remembered a few hours later. And the token-link was saved in my browser history from when i clicked it. HOWEVER, when you said that the code says the message was important, this made me curious enough to check out the code. And there it is: > SendingPage.qml: console.log("ERRROR" + msg) Therefore: > journalctl | grep ERRROR > Sep 27 20:44:32 drkonqi-coredump-launcher[2176]: qml: ERRRORError transferring https://bugs.kde.org/rest/bug?token=TOKEN - server replied: > Sep 27 20:44:56 drkonqi-coredump-launcher[2176]: qml: ERRRORError transferring https://bugs.kde.org/rest/bug?token=TOKEN - server replied: > Sep 27 20:44:56 drkonqi-coredump-launcher[2176]: qml: ERRRORError transferring https://bugs.kde.org/rest/bug?token=TOKEN - server replied: > Sep 27 20:46:01 drkonqi-coredump-launcher[2176]: qml: ERRRORError transferring https://bugs.kde.org/rest/bug?token=TOKEN - server replied: > Sep 27 20:46:01 drkonqi-coredump-launcher[2176]: qml: ERRRORError transferring https://bugs.kde.org/rest/bug?token=TOKEN - server replied: > Sep 27 20:46:01 drkonqi-coredump-launcher[2176]: qml: ERRRORError transferring https://bugs.kde.org/rest/bug?token=TOKEN - server replied: > Sep 27 20:46:04 drkonqi-coredump-launcher[2176]: qml: ERRRORError transferring https://bugs.kde.org/rest/bug?token=TOKEN - server replied: > Sep 27 20:46:04 drkonqi-coredump-launcher[2176]: qml: ERRRORError transferring https://bugs.kde.org/rest/bug?token=TOKEN - server replied: > Sep 27 20:46:04 drkonqi-coredump-launcher[2176]: qml: ERRRORError transferring https://bugs.kde.org/rest/bug?token=TOKEN - server replied: > Sep 27 20:46:04 drkonqi-coredump-launcher[2176]: qml: ERRRORError transferring https://bugs.kde.org/rest/bug?token=TOKEN - server replied: > Sep 27 20:46:17 drkonqi-coredump-launcher[2176]: qml: ERRRORError transferring https://bugs.kde.org/rest/bug?token=TOKEN - server replied: > Sep 27 20:46:17 drkonqi-coredump-launcher[2176]: qml: ERRRORError transferring https://bugs.kde.org/rest/bug?token=TOKEN - server replied: > Sep 27 20:46:17 drkonqi-coredump-launcher[2176]: qml: ERRRORError transferring https://bugs.kde.org/rest/bug?token=TOKEN - server replied: > Sep 27 20:46:17 drkonqi-coredump-launcher[2176]: qml: ERRRORError transferring https://bugs.kde.org/rest/bug?token=TOKEN - server replied: > Sep 27 20:46:17 drkonqi-coredump-launcher[2176]: qml: ERRRORError transferring https://bugs.kde.org/rest/bug?token=TOKEN - server replied: > Sep 27 20:53:41 drkonqi-coredump-launcher[2176]: qml: ERRRORError transferring https://bugs.kde.org/rest/bug?token=TOKEN - server replied: > Sep 27 20:53:41 drkonqi-coredump-launcher[2176]: qml: ERRRORError transferring https://bugs.kde.org/rest/bug?token=TOKEN - server replied: > Sep 27 20:53:41 drkonqi-coredump-launcher[2176]: qml: ERRRORError transferring https://bugs.kde.org/rest/bug?token=TOKEN - server replied: > Sep 27 20:53:41 drkonqi-coredump-launcher[2176]: qml: ERRRORError transferring https://bugs.kde.org/rest/bug?token=TOKEN - server replied: > Sep 27 20:53:41 drkonqi-coredump-launcher[2176]: qml: ERRRORError transferring https://bugs.kde.org/rest/bug?token=TOKEN - server replied: > Sep 27 20:53:41 drkonqi-coredump-launcher[2176]: qml: ERRRORError transferring https://bugs.kde.org/rest/bug?token=TOKEN - server replied: And before you ask: What about the text after "server replied:"? I am pretty certain that this is the reason why i did not record the error message: There was just nothing. The only thing making me worried is that the token is really censored like this in the log. I did not censor the token this time. Unrelated things i came up with: 1. If the crash report could not be sent, the error message could be added to the crash report, so if the report is saved manually, this information is not lost. 2. Much more complicated: If the crash report could not be sent, the user can click "Send later automatically". Then the report, reason why sending failed and the KDE credentials are saved locally. Sending is then retried once per day for up to one month or so. I added a cut from my journal when submission failed to the attachments. Created attachment 174887 [details]
Section from journalctl
A short excerpt from when the submission failed. Tell me if you need more.
As i just saw the error log says "203", but i am quite certain this was not shown in the GUI. |