GNOME Bugzilla – Bug 599799
Crashes when inserting a row
Last modified: 2009-10-28 22:22:35 UTC
Created attachment 146353 [details] Spreadsheet example The spreadsheet will open to A3501. Press <Alt> I R (insert row) and the program will terminate instantly. Inserting a row is possible from some but not all cells. This spreadsheet was imported as a text file, and has not been edited much.
As far as I can tell, you can insert a row at or below A5190, but not at A5189 or above. If you delete cells from the bottom, e.g. delete A6000:B8277, the "crash point" will move.
I cannot reproduce this problem. If you start gnumeric from a terminal window (run "command"), do you get any kind of messages? Also, a stack trace would be nice if you have the tools to get that.
Version 1.8 works on Ubuntu, but version 1.9.1 always fails on two different Win XP computers. No error message on command window. A stack trace. Tools as in gcc? No, I don't have that.
If you really meant 1.9.1, that's pretty old by now. Any chance of testing 1.9.12 from http://www.gnome.org/~jody/gnumeric/win32/ ?
File gnumeric-1.9.12-20090902-debug.exe , default installation. Results were identical. No error message. There's probably a loose pointer somewhere. I don't know why it's acting differently on your computer.
This might be bug 92131.
Yes, I suppose it might be. If I convert the entries in column A to values, it doesn't crash. I don't understand why you can't duplicate the problem, however, unless maybe it has something to do with resources. I've tried it on four Win XP computers, and it always terminates. All are Dells, fairly modestly configured. Three are old. The newest and best has 1 GB of memory. The new one is virtually unused, and has almost nothing else installed, so there's nothing unusual about the configuration.
But they are all Win XP machines.
> I don't understand why you can't duplicate the problem, however The problem exists mostly on Win32. Most of us here run Linux. "Mostly" because it is possible to trigger this kind of problem on Linux too, but since we set the stack size very big, it takes a good deal of effort to trigger it. We need to figure out how to do the same thing for Win32. *** This bug has been marked as a duplicate of bug 92131 ***
Some info on stack sizes: http://cs.nyu.edu/exact/core/doc/stackOverflow.txt
Thanks for the reference. I've been plagued by stack overflows with some of my software too. It doesn't take much. According to that reference, if it's compiled with gcc, it's a matter of running the binary through editbin. Kind of a pain and a bit easy to forget, but it beats ignominious crashes, I guess. Seems like maybe a gcc bug.