GNOME Bugzilla – Bug 447102
Bub-Buddy: Unable to parse XML-RPC Response
Last modified: 2008-01-30 18:16:59 UTC
Please describe the problem: Bug Buddy has encountered an error while submitting your report to the Bugzilla server. Details of the error are included below. Failed to parse the xml-rpc response. Response follows: Unable to parse XML-RPC Response 3 <?xml version="1.0" encoding="UTF-8"?> <methodResponse><fault><value><struct><member><name>faultString</name><value><string>Application failed during request deserialization: not well-formed (invalid token) at line 780, column 0, byte 45914 at /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/XML/Parser.pm line 187 </string></value></member><member><name>faultCode</name><value><string>Client</string></value></member></struct></value></fault></methodResponse> Steps to reproduce: 1. Encounter a reportable problem that can be intecepted by Bug-Buddy 2. Review Crash details and press the 'Send' button 3. En error message appears. Actual results: An error message appears saying that Bug-Buddy Failed to parse the xml-rpc response with some xml code provided. Expected results: Bug-Buddy had to submit a new bug. Does this happen every time? Yes, sice I moved from Gnome 2.16 to 2.18.1 Other information: Using Gentoo AMD64 OS Compiled for Nocona arch.
I think this is the same problem that I am having. The issue (for me at least) is caused by "strange" unicode characters in the original stack trace. From Bug 448288 as a typical example the report contains -------- Backtrace was generated from '/usr/bin/evolution' [?1034hUsing host libthread_db library "/lib64/libthread_db.so.1". [Thread debugging using libthread_db enabled] -------- The workarounds are 1. Edit the report before sending to remove the "[?1034h", or 2. Submit the report on the web site. Neither option is very friendly to the average user and I am sure we are missing many reports because of it.
It is definitely the same problem. I'll attach a test case (a recent Evolution stack trace). The output in poor Bug Buddy: -------- Failed to parse the xml-rpc response. Response follows: Unable to parse XML-RPC Response 3 <?xml version="1.0" encoding="UTF-8"?> <methodResponse><fault><value><struct><member><name>faultString</name><value><string>Application failed during request deserialization: not well-formed (invalid token) at line 23, column 0, byte 1587 at /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/XML/Parser.pm line 187 </string></value></member><member><name>faultCode</name><value><string>Client</string></value></member></struct></value></fault></methodResponse> --------
Created attachment 90128 [details] Example stack trace that Bug Buddy barfs on An example stack trace generated by Evolution (Tasks) that Bug Buddy crashes on.
Both reported instances are on the 64-bit platform -- I do not know if this is significant but thought I'd highlight it as I didn't make it 100% clear I am on Fedora 7 x86_64 (it is in Comment #2 if you read it very carefully).
Allan, thanks a lot for your debugging here. I have the same problem on my x86_64 box. The code on the send by bug-buddy (including those control chars) is UTF-8 valid, but probably not XML-valid (because XML specs doesn't allow some UTF-8 control chars). probably bug-buddy should remove then from the output coming from gdb... but this is a gdb bug.
Hi Fernando! > The code on the send by bug-buddy (including those control chars) is UTF-8 valid, but probably not XML-valid (because XML specs doesn't allow some UTF-8 control chars). The code is ESC [ ? 1 0 3 4 h which looks like a terminfo-style screen formatting code. It is valid output in most reasonable encoding systems that I can think of, but you are right (and I learned something new today): the control characters in the range [#xE-#x1F], which obviously include ESC #x1B, are not allowed by the XML standard; see http://www.w3.org/TR/REC-xml/#charsets > probably bug-buddy should remove then from the output coming from gdb... but this is a gdb bug. I disagree. Bug-buddy should make no assumptions that the underlying program is well-behaved -- indeed it is almost per definition buggy -- and should not fail to report ANY output. This is a bug in bug-buddy. It should be fairly easy to escape any control characters that is outside the valid range (#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]) with some internal syntax. (You obviously can't use the &xnnnn; syntax as that must map to a XML-valid character.) I am loath to just remove the data completely, but that is a possible approach.
Would you like to make a patch for this?
Ok, fixed for 2.22