GNOME Bugzilla – Bug 645209
Unlinked dynamic deps not cleared correctly
Last modified: 2011-03-21 17:17:10 UTC
Open sample attached to #643873, select the third chart (the axes are not properly positioned), select Porperties, X-axis, posiiton, cross at low and validate, then quit gnumeric: crash. Backtrace is:
+ Trace 226384
Nothing related to axis change, just open the property box for the chart, validate without any change, and quit without saving.
Looks like a dangling pointer. Memory has been reused. ==13599== Invalid read of size 8 ==13599== at 0x4EE24D5: dep_hash_destroy (dependent.c:2208) ==13599== by 0x4EE2CA4: do_deps_destroy (dependent.c:2447) ==13599== by 0x4EE3402: dependents_workbook_destroy (dependent.c:2638) ==13599== by 0x4FA9CF3: workbook_dispose (workbook.c:105) ==13599== by 0x86EA540: g_object_unref (in /usr/lib64/libgobject-2.0.so.0.2200.4) ==13599== by 0x50160B2: dialog_quit (dialog-quit.c:464) [...] ==13599== Address 0xe7f16f0 is 720 bytes inside a block of size 1,280 free'd ==13599== at 0x4C242BD: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==13599== by 0x7B74F47: ??? (in /usr/lib64/libcairo.so.2.10800.8)
More valgrind magic, this time on a 32-bit machine: ==6832== Invalid read of size 4 ==6832== at 0x40B7B83: dep_hash_destroy (dependent.c:2208) ==6832== by 0x40B8066: do_deps_destroy (dependent.c:2447) ==6832== by 0x40B9374: dependents_workbook_destroy (dependent.c:2638) ==6832== by 0x416AB5C: workbook_dispose (workbook.c:105) ==6832== by 0x4EC3DDB: g_object_unref (in /lib/libgobject-2.0.so.0.2800.0) ==6832== by 0x41D8CF0: dialog_quit (dialog-quit.c:464) [...] ==6832== Address 0x8f0ac7c is 28 bytes inside a block of size 52 free'd ==6832== at 0x4028053: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==6832== by 0x4F665E5: g_free (in /lib/libglib-2.0.so.0.2800.0) ==6832== by 0x4F7E7DD: g_slice_free1 (in /lib/libglib-2.0.so.0.2800.0) ==6832== by 0x4EE805D: g_type_free_instance (in /lib/libgobject-2.0.so.0.2800.0) ==6832== by 0x4EC3EA8: g_object_unref (in /lib/libgobject-2.0.so.0.2800.0) ==6832== by 0x4351515: gog_graph_unref_data (gog-graph.c:688) ==6832== by 0x437EFFB: gog_dataset_set_dim_internal (gog-data-set.c:171) ==6832== by 0x437F1DC: gog_dataset_set_dim (gog-data-set.c:112) ==6832== by 0x4378992: gog_series_set_dim (gog-series.c:979) ==6832== by 0x72B561D: XL_gog_series_set_dim (ms-chart.c:2456) gog-graph.c:688 is a like that unrefs a GOData object which, clearly, is linked into dependencies somehow. While not causing this problem, I note that the unref should be swapped with the line after line where "dat" is being used (as a pointer).
Barking up the wrong tree... Something goes wrong during load, although valgrind doesn't show it. Note the G_SLICE setting. G_SLICE=always-malloc ../libtool --mode=execute gdb --args ./gnumeric ~/Download/2011-03\ Sales.xlsx [...] Program received signal SIGSEGV, Segmentation fault. 0xb6d8e848 in _int_malloc () from /lib/libc.so.6 (gdb) where
+ Trace 226391
Got it: ==15203== Invalid write of size 4 ==15203== at 0x7403BFF: xlsx_draw_color_themed (xlsx-read-drawing.c:793) ==15203== by 0x4568577: ??? (in /usr/lib/libgsf-1.so.114.0.19) ==15203== by 0x45686B9: ??? (in /usr/lib/libgsf-1.so.114.0.19) ==15203== by 0x4568C03: ??? (in /usr/lib/libgsf-1.so.114.0.19) ==15203== by 0x45D0117: xmlParseStartTag (parser.c:8285) When ensures that ->gocolor remains valid?
Ah, thanks a lot, my bad then.
Fixed the gocolor issue, but it still crashes. valgrind doesn't find anything before dep_hash_destroy call.
I see that too. It is not necessary to do anything before quitting.
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.