Help Needed: Memory/address problems
Dear Devs,
In a clean up on gradient/sp-stop code[1] I've gotten it all working, but for the style-test program itself which crashes with a stack guard error "stack smashing error". The problem only appears if you compile with `-fstack-protector` which is default ON for Ubuntu, but is not for windows and other OSes.
I attempted to use Valgrind (with --tool=exp-sgcheck) but that crashed too. Possibly because of the stack-protector which I can't seem to turn off.
I wanted to also try `-fsanitize=address` to winkle out the problem, but I have no idea where to add CFLAGS in CMake/ninja. So without being able to try other build options, I'm very lost.
Any help would be brilliant.
Best Regards, Martin Owens
On Thu, Oct 04, 2018 at 06:41:46PM -0400, doctormo@...400... wrote:
Dear Devs,
In a clean up on gradient/sp-stop code[1] I've gotten it all working, but for the style-test program itself which crashes with a stack guard error "stack smashing error". The problem only appears if you compile with `-fstack-protector` which is default ON for Ubuntu, but is not for windows and other OSes.
I attempted to use Valgrind (with --tool=exp-sgcheck) but that crashed too. Possibly because of the stack-protector which I can't seem to turn off.
I wanted to also try `-fsanitize=address` to winkle out the problem, but I have no idea where to add CFLAGS in CMake/ninja. So without being able to try other build options, I'm very lost.
Any help would be brilliant.
IIRC, stack smashing checks for out of bounds access on arrays, and is done at the kernel level; it's not intended to be turned off (other than building your own kernel I guess), it usually indicates a valid error. Your code doesn't appear to actually manipulate arrays directly, but maybe something is being modified implicitly? Does the error provide any backtrace or more detailed error message that might indicate where it's failing? The valgrind output might be interesting too.
Bryce
Best Regards, Martin Owens
[1] https://gitlab.com/inkscape/inkscape/merge_requests/348
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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
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=OFF
Thomas
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
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
On Fri, Oct 05, 2018 at 11:46:11AM -0400, doctormo@...400... wrote:
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.
Yeah could totally see that cause an ABI break, that could cause an error such as this. Maybe the test building logic needs better dependency checking? Is this specific to the ninja build scripting?
Bryce
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
participants (3)
-
unknown＠example.com -
Bryce Harrington -
Thomas Holder