GNOME Bugzilla – Bug 743597
segfault in goc_canvas_invalidate_region
Last modified: 2018-05-22 14:16:25 UTC
Created attachment 295580 [details] vulnerable to segfault It might be good to take a look at goc_canvas_invalidate_region. I've been getting segfaults. The "priv" pointer is zero. The attached file demonstrates the problem. Type a single "=" sign in cell A1 (or anywhere else) and then click on cell B1 (or anywhere else). Observe immediate segfault. This is not urgent for me; there are lots of obvious ways of patching the code to make the problem go away. Somebody who knows more than me can decide what is best. $x/gnumeric --version gnumeric version '1.12.20' datadir := '/usr/src/gnumeric/gitball/gnumeric/1.12.20' libdir := '/usr/src/gnumeric/gitball/' uname -a Linux asclepias 3.18.0+ #2 SMP Sun Dec 21 18:25:03 MST 2014 x86_64 x86_64 x86_64 GNU/Linux
works fine for me....
works for me as well.
Which goffice version? Can you provide a stack trace? GcoCanvas::priv is initaliazed in goc_canvas_init() it can't be NULL unless some code changes it, but this should just not happen.
This is quite strange. Could you try running under Valgrind?
Status update: I have recompiled since the original report. Now I am getting a different symptom: not segfault, but other very weird behavior. Smells like memory corruption, but hard to be sure. Previously it was 100% reproducible chez moi; now it is only about 30% reproducible, but sticky. That is to say, sometimes when I start the program, it works fine, but other times it goes bad. Once a bad instance is started, it does bad things repeatedly. The details probably don't mean much, but here are the latest observations: Start the program Type an = sign in cell A1 Click on B1. In good mode, this enters into A1 a reference to B1. In bad mode, it just /selects/ B1, leaving just an = sign in A1. Further typing and further clicks behave the same. I'll do some valgrinding when I get a chance.
Created attachment 295682 [details] output from valgrind memcheck
Created attachment 295683 [details] output from valgrind sgcheck
A clue: With valgrind --malloc-fill=00 $x/gnumeric segfault.gnumeric I observed bad behavior 5 times in a row. With valgrind --malloc-fill=99 $x/gnumeric segfault.gnumeric i.e. different fill, I observed normal behavior 10 times in a row.
It looks like you are running Gnumeric from the build tree. There's a libtool wrapper in the way at that point. The best way to valgrind there is to do something like cd .../src ../tools/gnmvalgrind ./gnumeric segfault.gnumeric This also sets various environment variables that improve the valgrind effectiveness.
Created attachment 295714 [details] gnmvalgrind results, as requested
There is, strangely, nothing in that valgrind report that suggests the program crashed.
The program behaves differently in each of the following cases: a) when run directly b) when run under valgrind --malloc-fill=0 c) when run under valgrind --malloc-fill=99 Note that gnmvalgrind seems always similar to case (c) above, not case (b), even when I ask for --malloc-fill=0. Strange, indeed.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/272.