<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-01-18 9:11 GMT+01:00 Stephan Bergmann <span dir="ltr"><<a href="mailto:sbergman@redhat.com" target="_blank">sbergman@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 01/16/2017 01:55 PM, Tomáš Chvátal wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
2017-01-16 11:55 GMT+01:00 Miklos Vajna <<a href="mailto:vmiklos@collabora.co.uk" target="_blank">vmiklos@collabora.co.uk</a><br></span>
<mailto:<a href="mailto:vmiklos@collabora.co.uk" target="_blank">vmiklos@collabora.co.u<wbr>k</a>>>:<span class=""><br>
    On Fri, Jan 06, 2017 at 10:56:04AM +0100, Tomáš Chvátal<br></span><span class="">
    <<a href="mailto:tomas.chvatal@gmail.com" target="_blank">tomas.chvatal@gmail.com</a> <mailto:<a href="mailto:tomas.chvatal@gmail.com" target="_blank">tomas.chvatal@gmail.co<wbr>m</a>>> wrote:<br>
    > Ah now i get it. Well it happens always on the same test:<br>
    ><br>
    > [  649s] trying to instantiate implementation<br>
    > "com.sun.star.wizards.agenda.C<wbr>allWizard"<br>
    > [  649s] unknown:0:(anonymous namespace)::Test::test<br>
    > [  649s] uncaught exception of type std::bad_alloc<br>
    > [  649s] - std::bad_alloc<br>
<br>
    Here is how I would continue debugging this. Add this after the<br>
    SAL_DEBUG() that prints the service name:<br>
<br>
    if (i.first == "com.sun.star.wizards.agenda.C<wbr>allWizard")<br>
        SAL_DEBUG("foo");<br>
<br>
    Then in gdb you can put a breakpoint on the SAL_DEBUG("foo"); line,<br>
    before the test attempts to instantiate<br>
    <a href="http://com.sun.star.wizards.agenda.Ca">com.sun.star.wizards.agenda.Ca</a><wbr>llWizard. When you hit the breakpoint, do<br>
    "catch throw" and "continue". Hopefully that'll show us where<br>
    std::bad_alloc is thrown.<br>
<br>
Hi, got to it and attaching the trace of the point. Seems like if I just<br>
break there and then catch the bad_alloc it stops on the right place<br>
finaly :)<br>
</span></blockquote>
<br>
Interestingly, <<a href="http://ci.libreoffice.org/job/lo_callgrind_linux/2588/" rel="noreferrer" target="_blank">http://ci.libreoffice.org/job<wbr>/lo_callgrind_linux/2588/</a>> started to fail in exactly the same way now, after (among other things) <<a href="https://cgit.freedesktop.org/libreoffice/core/commit/?id=743f9fc86f3d3b6e87bf58c0654bcdccab0ab383" rel="noreferrer" target="_blank">https://cgit.freedesktop.org/<wbr>libreoffice/core/commit/?id=74<wbr>3f9fc86f3d3b6e87bf58c0654bcdcc<wbr>ab0ab383</a>> "python3: upgrade to release 3.5.3".<br>
<br>
I assume you are (implicitly) using --enable-python=system in your failing build?  If yes, is that a 3.5.3, too?  Maybe that's the direction to search in.  Or did you already track the problem down?<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div>Yep we are of course using the system python, but I actually even backtracked the problem to the issue that python uno failed to load due to SUSE patch, which I removed now and it seems happily passing over. I still didn't produce workable binaries so I am waiting on that to say if I am safely out of water.</div><div><br></div><div>Cheers</div><div><br></div><div>Tom </div></div></div></div>