abrt 1.1.1 detected a crash. architecture: x86_64 Attached file: backtrace cmdline: /usr/lib64/openoffice.org3/program/simpress.bin -impress component: openoffice.org crash_function: operator-= executable: /usr/lib64/openoffice.org3/program/simpress.bin global_uuid: db6d8a92d91f9dec0273e8a3c92e20e3ff26f470 kernel: 2.6.33.5-112.fc13.x86_64 package: openoffice.org-impress-1:3.2.0-12.24.fc13 rating: 4 reason: Process /usr/lib64/openoffice.org3/program/simpress.bin was killed by signal 11 (SIGSEGV) release: Fedora release 13 (Goddard) How to reproduce ----- 1. Run ooimpress 2. Edit 8.4MB file for a while 3. Crash
Created attachment 424003 [details] File: backtrace
I see one use of uninitialized value in StatusBar under valgrind that might be related to this, but I doubt it somehow... Can you reproduce the crash? What were you doing when it happened?
I'm not clear how to reproduce. But I found a heavy disk access before crash. I don't remember the RES and SHR in top command. However VIRT is about 2.8GB. My Fedora box has 3081MB memory and 5117MB swap. When the crash occurred, I edit a 8.5MB odp file for about one or two hour with firefox, thunderbird and GNOME desktop.
Do you still have the .odp, maybe there's some embedded format or something inside it that does something interesting on save with the status bar. ---- sd/source/ui/view/drviewsa.cxx does have... if( SFX_ITEM_AVAILABLE == rSet.GetItemState( SID_ATTR_ZOOMSLIDER ) ) { ... SdrPageView* pPageView = mpDrawView->GetSdrPageView(); if( pPageView ) { ... } } ... Point aPos = GetActiveWindow()->PixelToLogic(maMousePos); mpDrawView->GetSdrPageView()->LogicToPagePos(aPos); which begs the question of why bother checking for non-NULL pPageView if its definitely going to dereference it afterwards anyway,
I still have the .odp file. I don't think I want to put the file here but I can send you directly. If you want to investigate this bug with my .odp file, please let me know.
Please ignore my comment #5.
Sure, send it on to me, it's worth a shot
I got the .odp, played around with it a bit and did some load/save under valgrind, but nothing jumped out at me as a source for this :-(
*** Bug 660508 has been marked as a duplicate of this bug. ***