GNOME Bugzilla – Bug 341675
Segmentation fault
Last modified: 2006-10-17 17:43:55 UTC
bug(Segmentation fault) when I want to copy several cells. I have circular cells in iterative calculations(about electric fields)? paul@bigBoss ~ $ LC_ALL=fr_FR gnumeric & [1] 997 paul@bigBoss ~ $ Reading file:///home/paul/Desktop/couplageec30.gnumeric [1]+ Segmentation fault LC_ALL=fr_FR gnumeric file: -rw-r--r-- 1 paul users 122405 May 13 20:29 couplageec30.gnumeric
Would it be possible for you to provide a sample file that exhibits the bug (with an exact description what to copy to crash the program)? Thanks
Knowing the exact version would help too.
first, I installed version:1.4.3-r2 with: ACCEPT_KEYWORDS="~x86" emerge =gnumeric-1.4.3-r2 (gentoo) the problem appears I install version:1.6.3 with: ACCEPT_KEYWORDS="~x86" emerge =gnumeric-1.6.3 the same problem appears You can find the file at http://webtransfer.free.fr/ the file is : couplageectest.gnumeric thanks for your help Paul
I have the file. Now what? If can load it can force a recalc using F9, but it does not crash. What is the operation that will make it crash? Is it the same thing every time?
Paul said that "bug(Segmentation fault) when I want to copy several cells." It would be nice to know which cells he wants to copy. I can copy various cell groups without problem. It would also be nice to know which options to gcc are used by your compilation via "emerge". We used to have issues with faulty optimizations.
the exact description what to copy to crash the program when I copy cell DN42 to DN43. it is difficult to give which options to gcc are used by my compilation because with emerge I have several complations, a small one is: i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I. -I./widgets -I./dialogs -I./tools -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libgsf-1 -I/usr/include/libxml2 -I/usr/include/libgoffice-1 -I/usr/include/gtk-2.0 -I/usr/include/libglade-2.0 -I/usr/include/libgnomeprint-2.2 -I/usr/include/libart-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/libgnomeprintui-2.2 -I/usr/include/libgnomecanvas-2.0 -O2 -pipe -fomit-frame-pointer -march=athlon-xp -mtune=athlon-xp -Wall -Wmissing-prototypes -Wsign-compare -Wpointer-arith -Wnested-externs -Wchar-subscripts -Wwrite-strings -Wdeclaration-after-statement -Wnested-externs -Wmissing-noreturn -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -Wmissing-declarations -MT gnumeric-pane.lo -MD -MP -MF .deps/gnumeric-pane.Tpo -c gnumeric-pane.c -fPIC -DPIC -o .libs/gnumeric-pane.o gnumeric-pane.c: In function `cb_pane_popup_menu': gnumeric-pane.c:166: warning: dereferencing type-punned pointer will break strict-aliasing rules If you want more information, it is posssible on http://webtransfer.free.fr/, file : compilation.txt thanks for your help Paul
Options to gcc are used by my compilation: CFLAGS="-O2 -pipe -fomit-frame-pointer -march=athlon-xp -mtune=athlon-xp" Thank you
The set of options is pretty normal. Could you try running under a debugger to get a stack trace? gdb `which gnumeric` run # Load sheet and make it crash where # Back trace should be printed here. quit It might be useful if you could replace "-fomit-frame-pointer" by "-g" in the compilation flags. That would help the debugger.
I noticed this in the log: collect.c: In function `callback_function_collect': collect.c:79: warning: implicit declaration of function `format_match_number' collect.c:79: warning: nested extern declaration of `format_match_number' Please also add a #include "number-match.h" near the top of collect.c
with gdb (no debugging symbols found) Reading file:///home/paul/Desktop/tapis/etude_ci/couplageectest.gnumeric ---Type <return> to continue, or q <return> to quit--- Program received signal SIGSEGV, Segmentation fault. 0xb7cc0b15 in gnm_expr_eval () from /usr/lib/libspreadsheet-1.6.3.so (gdb) where
+ Trace 68234
Hmm... That stack trace would suggest that evaluation ends up going too deep. That would be bug 92131.
1.6.3 doesn't crash for me with the default stack limit - 8192 kb. If I reduce it to 8000, I get the crash. Conclusion: This is indeed bug 92131. 1.7.2 contains code to increase the stack size available for this. That's not a fix for 92131 in general, but takes this particular sheet way out of the danger zone. *** This bug has been marked as a duplicate of 92131 ***