On 01/16/2017 01:55 PM, Tomáš Chvátal wrote:
2017-01-16 11:55 GMT+01:00 Miklos Vajna <[email protected] <mailto:[email protected]>>: On Fri, Jan 06, 2017 at 10:56:04AM +0100, Tomáš Chvátal <[email protected] <mailto:[email protected]>> wrote: > Ah now i get it. Well it happens always on the same test: > > [ 649s] trying to instantiate implementation > "com.sun.star.wizards.agenda.CallWizard" > [ 649s] unknown:0:(anonymous namespace)::Test::test > [ 649s] uncaught exception of type std::bad_alloc > [ 649s] - std::bad_allocHere is how I would continue debugging this. Add this after the SAL_DEBUG() that prints the service name: if (i.first == "com.sun.star.wizards.agenda.CallWizard") SAL_DEBUG("foo"); Then in gdb you can put a breakpoint on the SAL_DEBUG("foo"); line, before the test attempts to instantiate com.sun.star.wizards.agenda.CallWizard. When you hit the breakpoint, do "catch throw" and "continue". Hopefully that'll show us where std::bad_alloc is thrown. Hi, got to it and attaching the trace of the point. Seems like if I just break there and then catch the bad_alloc it stops on the right place finaly :)
Interestingly, <http://ci.libreoffice.org/job/lo_callgrind_linux/2588/> started to fail in exactly the same way now, after (among other things) <https://cgit.freedesktop.org/libreoffice/core/commit/?id=743f9fc86f3d3b6e87bf58c0654bcdccab0ab383> "python3: upgrade to release 3.5.3".
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?
_______________________________________________ LibreOffice mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice
