GNOME Bugzilla – Bug 490591
"Paste values" of big areas uses excessive amounts of memory
Last modified: 2010-01-03 19:08:26 UTC
Steps to reproduce: 1. On a 2GB RAM 64 bits PC create a sheet with 4000 X IV "=rand()" for ex. 2. Copy all cells over themselves using "VALUES". 3. Gnumeric should crash (Pls read below) Stack trace: 1. I do almost all my gnumeric work on my 512MB RAM/1GB swap laptop. 2. I used to build Big .csv files, using a python program, which I copy values into a .gnumeric big book that has lots of sheets and charts depending on those values. 3. This *always* works fine. 4. Trying the same on my 2GB RAM/2x1.5GB swap crashes gnumeric when pasting values (it seems to happen at the end of the past when redrawing the window). Here is the console output: 02:07:12 Sex Out 26 PS ~/EM_CURSO/EstInvest/tt $ gnumeric AllData.csv AllData.gnumeric ** (gnumeric:1293): WARNING **: Using default value '1' Reading file:///AllData.csv Reading file:///AllData.gnumeric (gnumeric:1293): Gdk-CRITICAL **: gdk_window_get_events: assertion `GDK_IS_WINDOW (window)' failed (gnumeric:1293): Gdk-CRITICAL **: gdk_window_set_events: assertion `GDK_IS_WINDOW (window)' failed The program 'gnumeric' received an X Window System error. This probably reflects a bug in the program. The error was 'BadWindow (invalid Window parameter)'. (Details: serial 23040 error_code 3 request_code 18 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) 5. I could reproduce the same symptoms just creating a big sheet with a funcion (rand for ex.) and copying all cells and pasting values. Handling big sheest reveals some unstability. I had a crash once during the copy, not the paste! Other information:
The problem is that we are running you out of memory. Specifically, when you paste numbers into default-sized columns like here, the columns will auto-size. That forces us to re-render (== translate the numbers into strings) which in turn makes us create a pango layout. With 1M cells, that takes a lot of memory. We have various projects on our list that as a side effect will reduce the amount of memory needed, but for now don't do this. The only relevance of 64-bit is that pointers take up more memory in 64-bit mode.
Are you talking about some "special" memory area that must reside in the RAM or the memory in general? I'm asking because this problem may occur when there is about 200MB free and never uses a single byte of the swap area. On my laptop I could see more than 50% of 1GB swap being used without any crash!
News: I have noticed that this problem only occurs if running gnumeric from a remote X session. *Never* happens when running it locally. I usually use my desktop, using a ssh -XCl wireless session on kde, from my laptop. I found strange that when I booted a 32 bits partition gnumeric presented the same symptoms. My desktop has 2Gb while my laptop has only 512Mb. Besides the laptop SW is almost a clone of that on the dekstop (32 bits). The binaries I use on the laptop are those compiled from gentoo ebuilds on the desktop. And the situation never occured on my laptop. So, I tried to run gnumeric locally (on the desktop) both on 32 and 64 bits partition and it seems to work fine. I could build an example that: 1. Runs on my laptop. 2. Runs on my desktop locally. 3. Crashes about 50% using a remote session. You may want to increase/decrease the number of lines. To run it: 1. gnumeric tp1.gnumeric tp2.gnumeric 2. select/copy all data from tp1 sheet1 3. paste as values on tp2 sheet2 (A1)
Because of the size of the files, I put them at http://homepage.esoterica.pt/~nx0yew/gnumeric/ They will be there until 2007-Nov-11.
Additional information: The problem only occurs if both books are opened simultaneously. ______________________________________________________________________ May be a new bug should be filed or the title of this one changed. General summary: bar.csv: A big file (For. ex. 27000 X M) foo.gnumeric: Any book Open a remote ssh kde session; X :1 xterm -display :1 In the xterm ssh -XCl user remotePCname startkde gnumeric foo.gnumeric bar.csv Select the data from bar.csv Copy it Paste it into any sheet of foo.gnumeric gnumeric crashes outputing (gnumeric:9152): Gdk-CRITICAL **: gdk_window_get_events: assertion `GDK_IS_WINDOW (window)' failed (gnumeric:9152): Gdk-CRITICAL **: gdk_window_set_events: assertion `GDK_IS_WINDOW (window)' failed The program 'gnumeric' received an X Window System error. This probably reflects a bug in the program. The error was 'BadWindow (invalid Window parameter)'. (Details: serial 16490 error_code 3 request_code 18 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Working situations: 1: Calling gnumeric twice gnumeric foo.gnumeric gnumeric bar.csv 2: Working locally, i.e. not using a ssh remote session. Any of these situations works fine.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report. The memory usage was lowered a lot recently. Andreas: the glib warnings are beyond our control and care. When glib runs out of memory, weird things happen.