<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<style id="x_outgoing-font-settings">
<!--
#x_response_container_BBPPID
        {font-family:initial;
        font-size:initial;
        color:initial}
-->
</style>
<div style="background-color:rgb(255,255,255); line-height:initial">
<div id="x_response_container_BBPPID" dir="auto" style="outline:none">
<div name="x_BB10" id="x_BB10_response_div_BBPPID" dir="auto" style="width:100%">
Very cool. Would explicitly setting the byte order for each field be a short term workaround? </div>
<div name="x_BB10" id="x_response_div_spacer_BBPPID" dir="auto" style="width:100%">
<br style="display:initial">
</div>
<div id="x_blackberry_signature_BBPPID" name="x_BB10" dir="auto">
<div id="x__signaturePlaceholder_BBPPID" name="x_BB10" dir="auto">Sent from my BlackBerry - the most secure mobile device - via the Rogers Network</div>
</div>
</div>
<div id="x__original_msg_header_BBPPID" dir="auto">
<table width="100%" style="background-color:white; border-spacing:0px; display:table; outline:none">
<tbody>
<tr>
<td colspan="2" style="padding:initial; font-size:initial; text-align:initial; background-color:rgb(255,255,255)">
<div style="border-right:none; border-bottom:none; border-left:none; border-top:1pt solid rgb(181,196,223); padding:3pt 0in 0in; font-family:Tahoma,"BB Alpha Sans","Slate Pro"; font-size:10pt">
<div id="x_from"><b>From:</b> eeppeliteloop@gmail.com</div>
<div id="x_sent"><b>Sent:</b> March 13, 2019 8:30 AM</div>
<div id="x_to"><b>To:</b> matthew.khouzam@ericsson.com</div>
<div id="x_cc"><b>Cc:</b> jonathan.rajotte-julien@efficios.com; dschaefer@blackberry.com; tracecompass-dev@eclipse.org; lttng-dev@lists.lttng.org</div>
<div id="x_subject"><b>Subject:</b> Re: [lttng-dev] [tracecompass-dev] Scalability</div>
</div>
</td>
</tr>
</tbody>
</table>
<br>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On Wed, Mar 13, 2019 at 8:13 AM Matthew Khouzam<br>
<matthew.khouzam@ericsson.com> wrote:<br>
><br>
> Hi Doug & Efficios,<br>
><br>
><br>
> I suspect the issue is with libbabeltrace-ctf. When opening the trace in Trace Compass, it failed saying the sequence was 2gb big. When opening in babeltrace, it OOMed with 2gb allocations. When opening with a hex editor, I saw 2gb allocations.<br>
<br>
Yes, byte order issues. Here's the fix:<br>
<<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_efficios_babeltrace_pull_103&d=DwIFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=NrrbvTHWa2Nbp_kAN0Hl1o3lM1WAwSes64uBjxjNhMc&m=mro2UhDCczUi0qeroLQR1acWtiyKnR0DeQlLZcufM9M&s=0QPaQrHAx605SVgAPeaZnF264NFCA44uOkcXdbV5dpA&e=">https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_efficios_babeltrace_pull_103&d=DwIFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=NrrbvTHWa2Nbp_kAN0Hl1o3lM1WAwSes64uBjxjNhMc&m=mro2UhDCczUi0qeroLQR1acWtiyKnR0DeQlLZcufM9M&s=0QPaQrHAx605SVgAPeaZnF264NFCA44uOkcXdbV5dpA&e=</a>>.<br>
<br>
Phil<br>
<br>
><br>
><br>
> On another subject, fixing the trace made it scale well in both babeltrace and Trace Compass.<br>
><br>
><br>
> I don't know why, data_length writes the wrong data. Hope this helps all parties.<br>
><br>
><br>
> BR,<br>
><br>
> Matthew<br>
><br>
> ________________________________<br>
> From: tracecompass-dev-bounces@eclipse.org <tracecompass-dev-bounces@eclipse.org> on behalf of Doug Schaefer <dschaefer@blackberry.com><br>
> Sent: Tuesday, March 12, 2019 2:50:29 PM<br>
> To: jonathan.rajotte-julien@efficios.com<br>
> Cc: lttng-dev@lists.lttng.org; tracecompass-dev@eclipse.org<br>
> Subject: Re: [tracecompass-dev] [lttng-dev] Scalability<br>
><br>
> I have attached the C file for a generator that creates a trace that reproduces the memory issue with babeltrace. The same issue happens with a custom program in the call to add a trace to a context.<br>
><br>
> I am using babeltrace that I get from my Ubuntu 18.04 distro. It has the version number 1.5.5.<br>
><br>
> Thanks for the help!<br>
><br>
> On Tue, 2019-03-12 at 15:47 +0000, Doug Schaefer wrote:<br>
><br>
> In the thread on the tracecompass list, I also mentioned that the babeltrace utility itself ran out of memory when reading the file. That's actually my biggest worry. I got around the generator issue by flushing every 100K events.<br>
><br>
> I'll create a quick generator that shows the same issue and post it in a bit.<br>
><br>
> Doug.<br>
><br>
> On Tue, 2019-03-12 at 11:34 -0400, Jonathan Rajotte-Julien wrote:<br>
><br>
> On Tue, Mar 12, 2019 at 03:23:23PM +0000, Doug Schaefer wrote:<br>
><br>
> It should be easy to generate a random one with the class I mentioned below<br>
><br>
> and fill it with 16 million events.<br>
><br>
><br>
> Not if the problem is in the generator code ;).<br>
><br>
><br>
> BTW, two of the int fields are 5 and 10<br>
><br>
> bits respectively, but I'm not sure that matters (or at least it shouldn't).<br>
><br>
><br>
> Make sure to check the endian-ness of those fields.<br>
><br>
><br>
> What class? Not sure I see any reference to any.<br>
><br>
><br>
> Since you are generating CTF the error can be in the generator code. Please<br>
><br>
> provide either a trace reproducing the issue or a base reproducer. It will be<br>
><br>
> much easier overall than us trying to reproduce it blindly.<br>
><br>
><br>
> Cheers.<br>
><br>
><br>
> _______________________________________________<br>
><br>
> lttng-dev mailing list<br>
><br>
> lttng-dev@lists.lttng.org<br>
><br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.lttng.org_cgi-2Dbin_mailman_listinfo_lttng-2Ddev&d=DwICAg&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=NrrbvTHWa2Nbp_kAN0Hl1o3lM1WAwSes64uBjxjNhMc&m=DWwlFfl5FD5R8-HPY3GfbG6l6m7y_o2gXPER8IkQstk&s=bPK6X3vufUtEAemGpslNIlIL4UslBsgK-SWnraL-e9g&e=">
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.lttng.org_cgi-2Dbin_mailman_listinfo_lttng-2Ddev&d=DwICAg&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=NrrbvTHWa2Nbp_kAN0Hl1o3lM1WAwSes64uBjxjNhMc&m=DWwlFfl5FD5R8-HPY3GfbG6l6m7y_o2gXPER8IkQstk&s=bPK6X3vufUtEAemGpslNIlIL4UslBsgK-SWnraL-e9g&e=</a><br>
><br>
><br>
> ---------------------------------------------------------------------<br>
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information
 by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission
 by unintended recipients is not authorized and may be unlawful.<br>
> _______________________________________________<br>
> lttng-dev mailing list<br>
> lttng-dev@lists.lttng.org<br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.lttng.org_cgi-2Dbin_mailman_listinfo_lttng-2Ddev&d=DwIFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=NrrbvTHWa2Nbp_kAN0Hl1o3lM1WAwSes64uBjxjNhMc&m=mro2UhDCczUi0qeroLQR1acWtiyKnR0DeQlLZcufM9M&s=0dykfQKNunY0J3PjBwLhAqvF-WUIJ-gk74D-duicVKI&e=">
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.lttng.org_cgi-2Dbin_mailman_listinfo_lttng-2Ddev&d=DwIFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=NrrbvTHWa2Nbp_kAN0Hl1o3lM1WAwSes64uBjxjNhMc&m=mro2UhDCczUi0qeroLQR1acWtiyKnR0DeQlLZcufM9M&s=0dykfQKNunY0J3PjBwLhAqvF-WUIJ-gk74D-duicVKI&e=</a><br>
</div>
</span></font>
</body>
</html>