<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 30, 2015 at 2:05 PM, Dmitry Moskalchuk <span dir="ltr"><<a href="mailto:dm@crystax.net" target="_blank">dm@crystax.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 30/09/15 21:21, Rene Rivera wrote:<br> > As the thread "Tests for 'develop' not showing" concluded.. The<br> > multi-GiB XML files from the CrystaX.NET runners are causing result<br> > processing to fail because of the large memory requirement to parse<br> > those large files. Please find the reason why those files are large.<br> > And correct it so that they aren't so large. Otherwise I'll be forced<br> > to remove them from the result tables.<br> <br> </span>Well, XML results was always large, as I remember. Maybe not 3 GiB, but<br> 1 or 2 GiB - I've seen that multiple times. These XML files are produced<br> by process_jam_log utility, no extra steps. I can't inspect them by eyes<br> thoroughly, of course, but what I see is completely correct - there are<br> just results of tests, nothing more. BTW, bjam.log for such big XML<br> reports are big too - specifically for CrystaX.NET-apilevel-19-armeabi<br> runner, bjam.log is 3 GiB too:<br> <br> $ du -ms bjam.log<br> 3181 bjam.log<br></blockquote><div><br></div><div>Which leads me to suspect that the 64K output limit is not being eonforced in your case for some reason. Could you:</div><div><br></div><div>a) Inspect the b2 invocation to see if the "-m64" option is getting added?</div><div>b) Inspect some of the b2 output log (or resulting processed capture files) to see if there are >64K command output?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> BTW, I'm wondering why HTML generation code depends on XML size? Does it<br> read whole XML file in memory before parsing it?<br></blockquote><div><br></div><div>Yes, it seems the XML library the report generator uses just reads the entire XML into memory. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> The only I can suggest right now is to split such runners by toolsets -<br> i.e. CrystaX.NET-apilevel-19-armeabi-gcc-4.9 and<br> CrystaX.NET-apilevel-19-armeabi-gcc-5 instead of common<br> CrystaX.NET-apilevel-19-armeabi. This, obviously, will reduce size of<br> XML reports, but it still will be big - 1.5 GiB each in this specific<br> case. This is not what I'd like to do though, since it looks ugly and<br> don't fix main problem anyway, just workaround it.<br></blockquote><div><br></div><div>Right.. That splitting would definitely avoid the current problem. But I understand it's not desirable for you.</div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-- Rene Rivera<br>-- Grafik - Don't Assume Anything<br>-- Robot Dreams - <a href="http://robot-dreams.net/" target="_blank">http://robot-dreams.net</a><br>-- rrivera/<a href="http://acm.org/" target="_blank">acm.org</a> (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail</div></div> </div></div>