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 712663 - Memory usage issue on saving a fuzzed .gnumeric file
Memory usage issue on saving a fuzzed .gnumeric file
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: import/export other
git master
Other Linux
: Normal critical
: ---
Assigned To: Morten Welinder
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2013-11-19 11:56 UTC by jutaky
Modified: 2013-11-19 18:50 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description jutaky 2013-11-19 11:56:02 UTC 
Memory usage issue on saving a fuzzed .gnumeric file.

Git versions of glib, goffice, gnumeric, libgsf and libxml2.

The file opens normally, but on Save As it consumes 10GB+ of RAM in my system and gnumeric process gets killed.

For a small file of 5.5KB this sounds odd, so here is the test case for inspection if it is a bug or a feature of the file.

Test case: http://jutaky.com/fuzzing/gnumeric_case_29298_3345.2gnumeric.gnumeric

--
Juha Kylmänen
Research Assistant, OUSPG
Comment 1 Morten Welinder 2013-11-19 12:41:30 UTC 
I am unable to provoke this behaviour.  Not with the gui, not with
ssconvert, not under valgrind.

Can you get a stack trace after it grows to, say, 1GB?
Comment 2 jutaky 2013-11-19 13:55:31 UTC 
Here is a trace when ssconvert is taking approximately 6GB of RAM.

Program received signal SIGINT, Interrupt.
0x00007fffef256cdf in g_base64_encode_step (in=0x7ffed1f5d800 "", len=4294967295, break_lines=1, out=0x7ffd77e2b800 'A' <repeats 76 times>, "\n", 'A' <repeats 76 times>, "\n", 'A' <repeats 46 times>..., 
    state=0x7fffffffdfc0, save=0x7fffffffe000) at gbase64.c:147
147	          *outptr++ = base64_alphabet [ ((c2 &0x0f) << 2) |
(gdb) bt

+ Trace 232798

  • #0 g_base64_encode_step
    at gbase64.c line 147
  • #1 gsf_base64_encode_step
    at gsf-utils.c line 647
  • #2 gsf_base64_encode_close
    at gsf-utils.c line 622
  • #3 gsf_base64_encode_simple
    at gsf-utils.c line 691
  • #4 gsf_xml_out_add_base64
    at gsf-libxml.c line 2047
  • #5 go_pixbuf_save
    at utils/go-pixbuf.c line 96
  • #6 go_image_save
    at utils/go-image.c line 770
  • #7 save_image_cb
    at app/go-doc.c line 501
  • #8 g_hash_table_foreach
    at ghash.c line 1526
  • #9 go_doc_write
    at app/go-doc.c line 511
  • #10 gnm_xml_file_save_full
    at xml-sax-write.c line 1459
  • #11 gnm_xml_file_save
    at xml-sax-write.c line 1491
  • #12 go_file_saver_save_real
    at app/file.c line 577
  • #13 go_file_saver_save
    at app/file.c line 848
  • #14 wbv_save_to_output
    at workbook-view.c line 1059
  • #15 wb_view_save_to_uri
    at workbook-view.c line 1096
  • #16 wb_view_save_as
    at workbook-view.c line 1132
  • #17 convert
    at ssconvert.c line 788
  • #18 main
    at ssconvert.c line 860 






Comment 3


Morten Welinder





          2013-11-19 18:00:52 UTC
        



Might be fixed with goffice update now.






Comment 4


jutaky





          2013-11-19 18:41:14 UTC
        



The patch seems to work. The test case no longer eats all the memory.






Comment 5


Morten Welinder





          2013-11-19 18:50:36 UTC
        



This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.