GNOME Bugzilla – Bug 491472
FMR when reading gnumeric-generated biff8 xls file
Last modified: 2007-10-29 19:47:55 UTC
Version: r16031 OS: Ubuntu Gutsy Note: chart-tests-excel.xls is from gnumeric/samples/excel/. Steps to reproduce: - ./ssconvert --export-type=Gnumeric_Excel:excel_biff8 chart-tests-excel.xls tmp1 - valgrind ./ssconvert --export-type=Gnumeric_Excel:excel_dsf tmp1 tmp2 Valgrind output: ==8944== Invalid read of size 4 ==8944== at 0x45D57D2: go_format_unref (go-format.c:3959) ==8944== by 0x4142997: value_release (value.c:519) ==8944== by 0x409E832: gnm_expr_free (expr.c:416) ==8944== by 0x40A3C1C: gnm_expr_top_unref (expr.c:2648) ==8944== by 0x4097F83: dependent_set_expr (dependent.c:390) ==8944== by 0x40B8D04: gnm_go_data_vector_finalize (graph.c:350) ==8944== by 0x46EBAEB: g_object_unref (in /usr/lib/libgobject-2.0.so.0.1400.1) ==8944== by 0x45FBC96: gog_graph_unref_data (gog-graph.c:588) ==8944== by 0x46299D8: gog_dataset_set_dim_internal (gog-data-set.c:166) ==8944== by 0x4629B09: gog_dataset_finalize (gog-data-set.c:192) ==8944== by 0x46226FD: gog_series_finalize (gog-series.c:319) ==8944== by 0x65AE4D5: gog_xy_series_finalize (gog-xy.c:1390) ==8944== Address 0x1 is not stack'd, malloc'd or (recently) free'd ==8944== ==8944== Process terminating with default action of signal 11 (SIGSEGV) ==8944== Access not within mapped region at address 0x1 ==8944== at 0x45D57D2: go_format_unref (go-format.c:3959) ==8944== by 0x4142997: value_release (value.c:519) ==8944== by 0x409E832: gnm_expr_free (expr.c:416) ==8944== by 0x40A3C1C: gnm_expr_top_unref (expr.c:2648) ==8944== by 0x4097F83: dependent_set_expr (dependent.c:390) ==8944== by 0x40B8D04: gnm_go_data_vector_finalize (graph.c:350) ==8944== by 0x46EBAEB: g_object_unref (in /usr/lib/libgobject-2.0.so.0.1400.1) ==8944== by 0x45FBC96: gog_graph_unref_data (gog-graph.c:588) ==8944== by 0x46299D8: gog_dataset_set_dim_internal (gog-data-set.c:166) ==8944== by 0x4629B09: gog_dataset_finalize (gog-data-set.c:192) ==8944== by 0x46226FD: gog_series_finalize (gog-series.c:319) ==8944== by 0x65AE4D5: gog_xy_series_finalize (gog-xy.c:1390)
Thanks -- you have been busy. When you run valgrind, there are a few options that makes the result more reliable. For example, where c2.xls is the middle biff8 file: G_SLICE=always-malloc ../libtool --mode=execute valgrind --freelist-vol=50000000 ./ssconvert c2.xls c3.xls 2>&1 | less With that, the first issue I see is the one below, i.e., we cannot read the file we wrote in pass 1. ==32599== Invalid read of size 4 ==32599== at 0x4C317CA: value_equal (value.c:677) ==32599== by 0x4F71D33: gog_graph_ref_data (gog-graph.c:549) ==32599== by 0x4F96800: gog_dataset_set_dim_internal (gog-data-set.c:161) ==32599== by 0x4F96A9C: gog_dataset_set_dim (gog-data-set.c:111) ==32599== by 0xF7B2D8A: xl_chart_import_error_bar (ms-chart.c:3129) ==32599== by 0xF7B39A9: ms_excel_chart_read (ms-chart.c:3392) ==32599== by 0xF7B3F0F: ms_excel_chart_read_BOF (ms-chart.c:3457) ==32599== by 0xF7A6A96: ms_read_OBJ (ms-obj.c:1268) ==32599== by 0xF785BEB: ms_escher_read_ClientData (ms-escher.c:1985) ==32599== by 0xF7863AD: ms_escher_read_container (ms-escher.c:2089) ==32599== by 0xF7863AD: ms_escher_read_container (ms-escher.c:2089) ==32599== by 0xF7863AD: ms_escher_read_container (ms-escher.c:2089) ==32599== Address 0xC6AB4E8 is 0 bytes inside a block of size 32 free'd ==32599== at 0x4A20288: free (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==32599== by 0x4BB44E2: gnm_expr_free (expr.c:416) ==32599== by 0x4BB4548: gnm_expr_top_unref (expr.c:2648) ==32599== by 0xF7B3967: ms_excel_chart_read (ms-chart.c:3399) ==32599== by 0xF7B3F0F: ms_excel_chart_read_BOF (ms-chart.c:3457) ==32599== by 0xF7A6A96: ms_read_OBJ (ms-obj.c:1268) ==32599== by 0xF785BEB: ms_escher_read_ClientData (ms-escher.c:1985) ==32599== by 0xF7863AD: ms_escher_read_container (ms-escher.c:2089) ==32599== by 0xF7863AD: ms_escher_read_container (ms-escher.c:2089) ==32599== by 0xF7863AD: ms_escher_read_container (ms-escher.c:2089) ==32599== by 0xF7863AD: ms_escher_read_container (ms-escher.c:2089) ==32599== by 0xF786817: ms_escher_parse (ms-escher.c:2156)
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.