Version: 4.4 (using KDE 4.4.5) OS: Linux when a kdevelop krash happend i wrote ~10 additional lines for version info and what had happend, but the Assistant was telling me /Comments cannot be longer than 65,535 characters../ the saveable kcrash file was 560199 bytes long. Reproducible: Didn't try Steps to Reproduce: trigger a crash in 45 Threads prog with strace depth of about 120 Actual Results: assistant won't send report Expected Results: assistant will send report or make it possible to remove some thread data (hence only on of these threads crasched)
*** Bug 266172 has been marked as a duplicate of this bug. ***
*** Bug 271154 has been marked as a duplicate of this bug. ***
*** Bug 302376 has been marked as a duplicate of this bug. ***
Some problem here, a crash report from digikam was > 200k, thanks to many boost-debug messages.
Just some notes for future implemnation. According to http://www.bugzilla.org/docs/4.2/en/html/api/Bugzilla/WebService/Bug.html : Errors 114 (Comment Too Long) You tried to add a comment longer than the maximum allowed length (65,535 characters). So that 65535 looks like a hard limit (no idea whethter that limit is configurable by sysadmins of bugs.kde.org). Anyway, DrKonqi should check the length of the full report text before sending it out. If it is above the limit, DrKonqi should first create the new bug report only contaiing system informtions, user description, minimum useful backtrace and posible duplicates, then upload the full report text as attachment (which now allows for 4MB, much safer than the 65535 limit for comment).
*** Bug 323083 has been marked as a duplicate of this bug. ***
Just ran into this too. I wonder whether it would make sense to strip the backtrace in the comment down to only the last thread. This would reduce the size of the BT in most cases drastically. The full non-stripped BT could still be attached, but this would ensure that the relevant lines are being posted inline and are therefor indexable for duplicate lookups, search engines etc.
*** Bug 344611 has been marked as a duplicate of this bug. ***
Created attachment 92223 [details] Screenshot I got the same error today.
Created attachment 92225 [details] DrKonqi will not submit bug report As you can see, DrKonqi is complaining about the length of the bug report, but the back button is disabled so I can't go back and fix it.
This just happened to me too. I can't send my report of Plasma crashing because the report is too long. Does anybody know if there is a way I can upload the report somewhere else? What would be safe to trim from the report so it fits the char limit?
Me too on the Plasma crashes with more than 40 and sometimes as many as 77 threads, just the stack trace is > 65K
(In reply to happy from comment #12) > Me too on the Plasma crashes with more than 40 and sometimes as many as 77 > threads, just the stack trace is > 65K Had the same happen to me just now.
Possible solutions: 1. Add option to paste whole backtrace in paste.kde.org service and insert link into description. 2. Add option to paste whole backtrace in attachment. 3. Paste beginning of backtrace in attachment/paste.kde.org and rest with max available characters in description/comment.
(In reply to Alexander Mentyu from comment #14) > Possible solutions: > 1. Add option to paste whole backtrace in paste.kde.org service and insert > link into description. > 2. Add option to paste whole backtrace in attachment. > 3. Paste beginning of backtrace in attachment/paste.kde.org and rest with > max available characters in description/comment. A variation of option 3: 4. Put the backtrace of the crashed thread in the comment and attach the backtrace of all threads. I think in most cases only the backtrace of the thread that actually crashed is relevant, but for the few cases where other threads are relevant, it would be nice to have access to the full backtrace dump.
*** Bug 385721 has been marked as a duplicate of this bug. ***
Git commit c07434bf8e2e6b488c4293b08c7cb7c56abdf728 by Harald Sitter. Committed on 12/07/2019 at 12:49. Pushed by sitter into branch 'master'. prevent exhausting the maximum size of bug reports Summary: bugzilla has a hardcoded server-side limit for how large a given comment may be. this can somewhat easily get triggered by heavily threaded applications as the backtrace would include a lot of "noise" threads. when this previously happened drkonqi would find itself incapable of filing the report and leaving the user to their own devices. now we are much smarter about this if the reportinterface finds that the bug description is too long it will try to use a reduced backtrace (only a couple of lines from the relevant thread) or when that too is too long to exclude the backtrace entirely. in both events it would then additionally attach the complete backtrace to the bug. for this there's a bunch of rejiggering necessary: - generateReportFullText has had its signature changed, instead of using a lazy bool now use enums to control the output. this should be vastly more readable - new Backtrace control on generateReportFullText ranging Complete> Redcued>Exclude - addedToCC was renamed to attachBacktraceWithReport which is a more suitable name for what it does. it's logic has been moved to a new attachBacktrace which requires the caller to set the actual comment - attachBacktrace is called with a full report comment when used via \ attachBacktraceWithReport (i.e. the user indicated that their crash is in fact the same as another report, so their report gets attached to the other one). it's called with a simplified message when attaching as part of a reduced/excluded backtrace dance the end result is that the reports can no longer exhaust the hardcoded character limit. there is one caveat: the user can still write a super long description manually and exhaust the limit. this is however very hard to do in real life without "abusing" the description for something. CHANGELOG: Bug reporting can no longer exhaust the maximum character size enforced by Bugzilla FIXED-IN: 5.17.0 Test Plan: - file bug report with ETOOLONGTRACE -> gets reduced and attached - regular attaching still works - exhausting the limit *exactly* works as expected Reviewers: #plasma, apol Reviewed By: apol Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D22399 M +2 -1 src/bugzillaintegration/reportassistantdialog.cpp M +5 -2 src/bugzillaintegration/reportassistantpages_base.cpp M +4 -2 src/bugzillaintegration/reportassistantpages_bugzilla.cpp M +76 -15 src/bugzillaintegration/reportinterface.cpp M +20 -3 src/bugzillaintegration/reportinterface.h https://commits.kde.org/drkonqi/c07434bf8e2e6b488c4293b08c7cb7c56abdf728
*** Bug 415100 has been marked as a duplicate of this bug. ***