Simple scan crashes when a PDF is saved
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Simple Scan |
Fix Released
|
High
|
Robert Ancell |
Bug Description
SOLUTION
*******
This was one of the most prominent bugs in Simple Scan for a long time.
It has been fixed in Simple Scan 3.3.92
Upgrade to Simple Scan 3.3.92, older versions are still affected but will not be fixed.
*******
When saving a PDF memory corruption occurs and simple scan crashes in random code (for me in the deflate functionality). Checked this using clean bzr checkout. BTW, I would have patched this much earlier if simple-scan was version control system that I was familiar with (like git) :S
Can be verified with valgrind:
** WARNING **: scanner.vala:1204: Scan completed with 2250 lines, expected 2250 lines
==8804== Thread 1:
==8804== Invalid write of size 1
==8804== at 0x40FCFA: book_save_pdf (book.c:1826)
==8804== by 0x411F20: book_save (book.c:2533)
==8804== by 0x44372F: simple_
==8804== by 0x447230: save_file_
==8804== by 0x66AFD53: g_cclosure_
==8804== by 0x66ADF59: g_closure_invoke (gclosure.c:774)
==8804== by 0x66C7C40: signal_
==8804== by 0x66C6E51: g_signal_
==8804== by 0x66C7507: g_signal_
==8804== by 0x4F14CBC: button_clicked (gtktoolbutton.
==8804== by 0x66AFD53: g_cclosure_
==8804== by 0x66ADF59: g_closure_invoke (gclosure.c:774)
==8804== Address 0x2102c5c8 is 0 bytes after a block of size 711,000 alloc'd
==8804== at 0x4A05BB4: calloc (vg_replace_
==8804== by 0x6947193: standard_calloc (gmem.c:104)
==8804== by 0x6947225: g_malloc0 (gmem.c:189)
==8804== by 0x69474E2: g_malloc0_n (gmem.c:385)
==8804== by 0x40F889: book_save_pdf (book.c:1674)
==8804== by 0x411F20: book_save (book.c:2533)
==8804== by 0x44372F: simple_
==8804== by 0x447230: save_file_
==8804== by 0x66AFD53: g_cclosure_
==8804== by 0x66ADF59: g_closure_invoke (gclosure.c:774)
==8804== by 0x66C7C40: signal_
==8804== by 0x66C6E51: g_signal_
==8804==
==8804== Invalid read of size 1
==8804== at 0x40FD0C: book_save_pdf (book.c:1827)
==8804== by 0x411F20: book_save (book.c:2533)
==8804== by 0x44372F: simple_
==8804== by 0x447230: save_file_
==8804== by 0x66AFD53: g_cclosure_
==8804== by 0x66ADF59: g_closure_invoke (gclosure.c:774)
==8804== by 0x66C7C40: signal_
==8804== by 0x66C6E51: g_signal_
==8804== by 0x66C7507: g_signal_
==8804== by 0x4F14CBC: button_clicked (gtktoolbutton.
==8804== by 0x66AFD53: g_cclosure_
==8804== by 0x66ADF59: g_closure_invoke (gclosure.c:774)
==8804== Address 0x2102c5c8 is 0 bytes after a block of size 711,000 alloc'd
==8804== at 0x4A05BB4: calloc (vg_replace_
==8804== by 0x6947193: standard_calloc (gmem.c:104)
==8804== by 0x6947225: g_malloc0 (gmem.c:189)
==8804== by 0x69474E2: g_malloc0_n (gmem.c:385)
==8804== by 0x40F889: book_save_pdf (book.c:1674)
==8804== by 0x411F20: book_save (book.c:2533)
==8804== by 0x44372F: simple_
==8804== by 0x447230: save_file_
==8804== by 0x66AFD53: g_cclosure_
==8804== by 0x66ADF59: g_closure_invoke (gclosure.c:774)
==8804== by 0x66C7C40: signal_
==8804== by 0x66C6E51: g_signal_
==8804==
The problem is that due to a integer rounding error, one byte less is allocated in the image buffer than there should be. I don't understand the code completely, so this patch should be verified by the original author of the code. Attached.
description: | updated |
description: | updated |
Awesome! I'll ping Robert about this, so he can double check.
I am quite optimistic that this might also fix Bug #664608 -- Then again, if it does, I should have bet some real money against Robert :)
About your git side blow: I have been thinking about this. The fragmentation of version control systems surely isn't really helping anyone, and it looks as if git was standing strong and gaining market share, unlike most (all?) alternatives, bazaar included. Then again, launchpad only supports bazaar right now, and I do not think giving up on launchpad is advisable for simple scan...