GNOME Bugzilla – Bug 725459
Gnumeric don't respond anymore after dublicating sheets
Last modified: 2014-03-04 16:37:16 UTC
Created attachment 270638 [details] Good luck Hello, I found another bug. Maybe it's somehow related to bug #724108, because it happens with the same file and it's similar strange. This file has already 132 sheets, so it is rather big. When I duplicate some sheets gnumeric hangs. It takes 100% CPU and don't respond anymore, so you have to kill the process. The best way to duplicate this bug is this: Open the testfile. Duplicate the 18th sheet, called 'Fez'. Then duplicate the 36th sheet, called 'Pisano'. On my tests the bug always occurs then. Tested with 1.12.11 on Ubuntu and 1.12.9 win-version running on wine. Duplicating other sheets sometimes causes the bug, too. I looked at console output of gnumeric. I displays this lines when loading my test file: ** (gnumeric:18728): WARNING **: Strangeness with defined name ** (gnumeric:18728): CRITICAL **: xml_sax_named_expr_prop: assertion `state->name.value == NULL' failed ** (gnumeric:18728): CRITICAL **: xml_sax_named_expr_prop: assertion `state->name.position == NULL' failed I think this is more interesting for the cause of bug #724108, but maybe it's related here, too. Other interesting things are not displayed in console output. Please lock if you can reproduce bug #724108 with my attached testfile, too. It should appear most of the times when opening it. Thanks.
Created attachment 270639 [details] Contains description of my unconfirmed bugs #725217 and #724108, too
I haven't looked at the listed criticals yet. The first duplication causes problems and the problems are related to names. ==4198== Invalid read of size 1 ==4198== at 0x4C2E4C1: strcmp (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==4198== by 0x639D9B8: g_str_equal (ghash.c:1706) ==4198== by 0x639D0DF: g_hash_table_lookup (ghash.c:386) ==4198== by 0x4EF9BF5: gnm_named_expr_collection_lookup (expr-name.c:283) ==4198== by 0x4EFA1F6: expr_name_lookup (expr-name.c:481) ==4198== by 0x4F6959B: parser_simple_val_or_name (parser.y:494) ==4198== by 0x4F6A404: yyparse (parser.y:616) ==4198== by 0x4F6DCAF: gnm_expr_parse_str (parser.y:1580) ==4198== by 0x50BA4D7: gee_update_lexer_items (gnumeric-expr-entry.c:1057) ==4198== by 0x50BD5FD: cb_entry_changed (gnumeric-expr-entry.c:1296) ==4198== by 0x6124187: g_closure_invoke (gclosure.c:777) ==4198== by 0x6135B1C: signal_emit_unlocked_R (gsignal.c:3586)
"Strangeness" here is caused by two names called Hahn and two called "Perutz". Obviously that should not have happened.
> "Strangeness" here is caused by two names called Hahn and two called > "Perutz". Obviously that should not have happened. I think this is not cause of the bug, instead maybe a symptom. This two names were exactly the ones which I added, because I don't found them in names list. I wanted to make all links leading to valid names for my test file, so I remember so good. Maybe the names were there, but they were not recognized when making the same name again. And the bug was there before I added this two names.
Criticals fixed. They may have caused the definition of the following name to change, so please verify these at some point. <gnm:name>Haifa</gnm:name> <gnm:name>Pessimist</gnm:name> But these things are unrelated to the duplication issue.
> Criticals fixed. They may have caused the definition of the following > name to change, so please verify these at some point. Yes, you're right. They cell address is still right, but the sheet name they belong is wrong. They now have the sheet name from the entry above them when displaying all names in alphabetic order. I always had little suspections of cell names vanishing sometimes in this file... I'm glad you took over and seem to have same first success to track down this bug(s). Thanks.
The trouble starts even earlier. We suffer widespread memory corruption sometime between the load finishes and the time we show the sheet. Specifically, wb->names->names suddenly contain names like "reload_page" and "nm-stage03-connecting02". Please hold off any more bugs based on this sheet until we figure out what is going on.
I have a handle on the problem. Will try to fix tonight.
Ok, names are fixed now. I am keeping open because I saw GtkNotebook acting up when duplicating the second sheet. It doesn't happen every time.
An infinite loop in sheet reordering triggered by sheet duplication has been fixed. This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.
Ok, thanks for your work here. When I have time for it, I will compile a fixed version of gnumeric and test. Maybe the fixed names remove bug #724108 now too.
I note that you have a pile of expressions like =vlookup(Blatt2!C1,Blatt2!$N$1:$O$5000,2,"false") VLOOKUP takes a *boolean* as its fourth argument, not a string. Removing the quotes would be the right thing to do. I'm not even sure what using the string will do if you run in a non-English locale.
Ah yes right, I think there was a bug with this, too. I will research what was the exact issue and eventually make a new bug report. Compiling and testing the fixed version has wait until tomorrow.
*** Bug 724108 has been marked as a duplicate of this bug. ***