After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 725459 - Gnumeric don't respond anymore after dublicating sheets
Gnumeric don't respond anymore after dublicating sheets
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: General
1.12.x
Other All
: Normal blocker
: ---
Assigned To: Jody Goldberg
Jody Goldberg
: 724108 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-03-01 18:27 UTC by Steff
Modified: 2014-03-04 16:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Good luck (1.26 MB, application/x-gnumeric)
2014-03-01 18:27 UTC, Steff
Details
Contains description of my unconfirmed bugs #725217 and #724108, too (89.26 KB, image/png)
2014-03-01 18:45 UTC, Steff
Details

Description Steff 2014-03-01 18:27:24 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.
Comment 1 Steff 2014-03-01 18:45:26 UTC
Created attachment 270639 [details]
Contains description of my unconfirmed bugs #725217 and #724108, too
Comment 2 Morten Welinder 2014-03-02 03:45:00 UTC
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)
Comment 3 Morten Welinder 2014-03-02 04:30:37 UTC
"Strangeness" here is caused by two names called Hahn and two called
"Perutz".  Obviously that should not have happened.
Comment 4 Steff 2014-03-02 05:32:51 UTC
> "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.
Comment 5 Morten Welinder 2014-03-02 15:13:56 UTC
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.
Comment 6 Steff 2014-03-02 17:01:06 UTC
> 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.
Comment 7 Morten Welinder 2014-03-02 18:08:39 UTC
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.
Comment 8 Morten Welinder 2014-03-02 20:59:55 UTC
I have a handle on the problem.  Will try to fix tonight.
Comment 9 Morten Welinder 2014-03-03 02:39:23 UTC
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.
Comment 10 Morten Welinder 2014-03-03 03:44:48 UTC
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.
Comment 11 Steff 2014-03-03 04:06:34 UTC
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.
Comment 12 Morten Welinder 2014-03-03 15:38:35 UTC
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.
Comment 13 Steff 2014-03-03 18:48:11 UTC
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.
Comment 14 Morten Welinder 2014-03-04 16:37:16 UTC
*** Bug 724108 has been marked as a duplicate of this bug. ***