<table><tr><td style="">sitter added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D28129">View Revision</a></tr></table><br /><div><div><p>Quick recap from what we talked about on telegram: putting the print after the bt is most definitely going to throw off the backtrace parsing logic, so doing it this way would require extensive changes there, which is a dangerous place to make extensive changes.<br />
Or we could define a simple function to ignore errors <a href="https://stackoverflow.com/questions/17923865/gdb-stops-in-a-command-file-if-there-is-an-error-how-to-continue-despite-the-er" class="remarkup-link" target="_blank" rel="noreferrer">https://stackoverflow.com/questions/17923865/gdb-stops-in-a-command-file-if-there-is-an-error-how-to-continue-despite-the-er</a> but that's also a bit faffy.<br />
Another completely standalone approach would be to change BacktraceGenerator (I think?) to invoke the print in a completely independent gdb invocation i.e. separate the print call from the regular batchcommands and have drkonqi assemble it back into the final report. That way the actual tracing batch command couldn't fail on the print.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R871 DrKonqi</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D28129">https://phabricator.kde.org/D28129</a></div></div><br /><div><strong>To: </strong>apol, Frameworks, broulik, sitter<br /><strong>Cc: </strong>plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart<br /></div>