abrt version: 1.1.17 architecture: x86_64 Attached file: backtrace, 34849 bytes cmdline: gnucash 2010.gnucash comment: The financial data is from 2010, so there would have been no entries for the current year. Defaults for the gl report (and subsiquent null output) might be a factor. component: gnucash Attached file: coredump, 107032576 bytes crash_function: WTF::OSAllocator::reserveAndCommit executable: /usr/bin/gnucash kernel: 2.6.35.11-83.fc14.x86_64 package: gnucash-2.4.4-2.fc14 rating: 4 reason: Process /usr/bin/gnucash was killed by signal 11 (SIGSEGV) release: Fedora release 14 (Laughlin) time: 1303936350 uid: 500 How to reproduce ----- 1. Opened the "reports" menu item 2. selected "general ledger". 3. CRASH.
Created attachment 495345 [details] File: backtrace
Assigning to webkitgtk; this is what crashed.
How much memory do you have there? Can you get it to crash everytime with this action?
*** Bug 707870 has been marked as a duplicate of this bug. ***
The crash always occurs. Rebuilding gnucash with --with-html-engine=gtkhtml is probably currently the easiest workaround.
If you do 'echo 1 > /proc/sys/vm/overcommit_memory' can you no longer get it to happen?
Nope, no crash after changing the kernel virtual memory accounting mode
ok, then this is another case of bug 648319 it sounds like. There's a fix commited upstream, but it's not in a release. I guess I can pull the patch into our f15 version at least. *** This bug has been marked as a duplicate of bug 648319 ***