Thanks Bryce and Thomas,
The problem has gone away once I forced ninja to rebuild the tests. This happened as I was commenting out test code to focus on the error.
But instead it looks like the error was caused by the tests never recompiling, even if you change the test's own cpp file and run `ninja` it remains stale. Running `ninja test` likewise doesn't rebuild the file and removing the binary bin/style-test resulted in errors rather than rebuilding.
Only `ninja bin/style-test` managed to rebuild it. and then the problem disappeared. Which explains why the crash was in the test code and not in Inkscape and also why the crash wasn't replicatable.
Best Regards, Martin Owens
On Fri, 2018-10-05 at 16:55 +0200, Thomas Holder wrote:
Hi Martin,
Just wondering: Do you have jemalloc enabled in your build? That caused weird behavior for me (mostly freezes) on Arch Linux. Problems were gone after rebuilding with:
-DWITH_JEMALLOC=OFFThomas
On 10/5/18 5:31 AM, doctormo@...400... wrote:
On Thu, 2018-10-04 at 19:45 -0700, Bryce Harrington wrote:
Does the error provide any backtrace or more detailed error message that might indicate where it's failing?
#5 0x00005555555aacf2 in (anonymous namespace)::StyleTest_Read_Test::TestBody() (this=0x555555858240) at ../testfiles/src/style-test.cpp:269 #6 0x00005555555e0821 in void testing::internal::HandleSehExceptionsInMethodIfSupported<testing:: Test , void>(testing::Test*, void (testing::Test::*)(), char const*) ()
Which means it's failing at the end of the assert, within the test code itself.
The valgrind output might be interesting too.
Even with the debug symbols, valgrind's backtrace is a just a row of question marks. Probably needs to be done a certain way to get output.
Nothing interesting in the valgrind memory leak check either.
Best Regards, Martin Owens