7105 2014-12-24 21:59:25 +0000 Error reporting class fails with large log file or long line 2015-03-27 14:45:23 +0000 1 1 6 Yocto Project Subprojects Error Reporting tool Error Reporting Tool unspecified x86 Multiple RESOLVED FIXED Medium normal 1.8 1 sgw michael.g.wood --- --- No (bug/feature does not impact docs) oldest_to_newest 47679 0 sgw 2014-12-24 21:59:25 +0000 This world build had a qt4 failure with long lines and large log. https://autobuilder.yoctoproject.org/main/builders/nightly-world/builds/140/steps/BuildImages/logs/stdio ERROR: Execution of event handler 'errorreport_handler' failed Traceback (most recent call last): File "errorreport_handler(e)", line 34, in errorreport_handler(e=<bb.event.BuildCompleted object at 0x7fa62c0dfc50>) **Excluded longline** if end != len(s): > raise ValueError(errmsg("Extra data", s, end, len(s))) return obj ValueError: Extra data: line 16 column 2 - line 24 column 2 (char 33262895 - 33502606) 48402 1 bluelightning 2015-01-29 15:20:27 +0000 That failure log is egregiously long - even the build log containing the (truncated) JSON is 207MB. We should deal with this, but I don't expect to see this too often so I'm downgrading the priority accordingly. I've just discussed this with Michael W, it looks like we might be hitting a limitation in the body size for HTTP requests and therefore the JSON error data is being truncated. There might be some workarounds but it might be that logs this large just aren't useful anyway, and we should make an attempt to prevent them from being uploaded or at the very least prevent send-error-report from blindly uploading them. 49872 2 michael.g.wood 2015-03-27 14:45:23 +0000 openembedded-core 5e036f3fd9caaedcd2759214766b3228299e929b - Add feature to check the server's max_log_size