Bug 659411 - [abrt] g_type_check_instance_cast in progress bar drawing (SIGSEGV)
[abrt] g_type_check_instance_cast in progress bar drawing (SIGSEGV)
Product: Fedora
Classification: Fedora
Component: libreoffice (Show other bugs)
x86_64 Unspecified
low Severity medium
: ---
: ---
Assigned To: Caolan McNamara
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-12-02 13:29 EST by Horst H. von Brand
Modified: 2011-02-09 11:45 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-02-09 11:45:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
File: backtrace (49.59 KB, text/plain)
2010-12-02 13:29 EST, Horst H. von Brand
no flags Details
Yum Log for Nov/Dec 2010 (138.07 KB, application/octet-stream)
2010-12-05 09:45 EST, Stephen
no flags Details
yum.log for dec 01 through dec 03 (13.69 KB, application/octet-stream)
2010-12-05 18:50 EST, Horst H. von Brand
no flags Details

  None (edit)
Description Horst H. von Brand 2010-12-02 13:29:10 EST
abrt version: 1.1.14
architecture: x86_64
Attached file: backtrace
cmdline: /usr/lib64/libreoffice/program/soffice.bin -quickstart -nologo -nodefault
comment: I had edited this file successfully before, printed it out (it is a form) and then exited oocalc without saving. Now I tried to open it again.
component: libreoffice
executable: /usr/lib64/libreoffice/program/soffice.bin
package: libreoffice-core-
reason: Process /usr/lib64/libreoffice/program/soffice.bin was killed by signal 11 (SIGSEGV)
release: Fedora release 15 (Rawhide)
time: 1291314393
uid: 500

How to reproduce
1. oocalc /tmp/Rec\ Gastos.xls
Comment 1 Horst H. von Brand 2010-12-02 13:29:12 EST
Created attachment 464323 [details]
File: backtrace
Comment 2 Horst H. von Brand 2010-12-02 13:31:03 EST
Tried opening the exact same file again (after trying in gnumeric), now it worked.
Comment 3 Caolan McNamara 2010-12-02 15:07:58 EST
Hmm, there's been a lot of those g_type_check_instance_cast crashes in the past. I think this is the first time we've gotten enough of a stacktrace to indicate that its the progressbar that's involved. 

Doesn't really help me to get closer to what's causing this.
Comment 4 Caolan McNamara 2010-12-02 15:35:00 EST
Could you attach your /var/log/yum.log. I wonder if this happens if gtk2 or glib or something gets upgraded while the (cursed) quickstarter is running.
Comment 5 Stephen 2010-12-05 08:17:38 EST
Package: libreoffice-core-
Architecture: x86_64
OS Release: Fedora release 15 (Rawhide)

How to reproduce
1. Attempted to start libreoffice using the command libreoffice -calc.  Nothing happened
2. Tried the command libreoffice on its own
3. Crash
Comment 6 Caolan McNamara 2010-12-05 08:26:09 EST
caolanm->stephen: Same question to you. Did you just do a yum update or otherwise upgrade your packages while logged into the desktop ?

i.e. did this happen because the quickstarter was running and something got upgraded while it was running. Please attach your /var/log/yum.log if you can.
Comment 7 Stephen 2010-12-05 09:45:10 EST
Created attachment 464852 [details]
Yum Log for Nov/Dec 2010

Attached is the YUM log entries for Nov and December this year.  I almost certainly did a Yum update whilst LibreOffice was running
Comment 8 Caolan McNamara 2010-12-05 11:20:44 EST
I wonder if upgrading "gtk-theme-engine-clearlooks" while running triggers this. Its a possibility at least
Comment 9 Horst H. von Brand 2010-12-05 18:50:38 EST
Created attachment 464905 [details]
yum.log for dec 01 through dec 03

There were no updates installed on dec 02 (the date of the crash), and I definitely had rebooted the machine after the update.
Comment 10 Horst H. von Brand 2010-12-06 15:31:40 EST
Package: libreoffice-core-
Architecture: x86_64
OS Release: Fedora release 15 (Rawhide)

How to reproduce
1. Closed oocalc's window

Had a window open for a while (was away from the machine), and tried to close via X on it; a dialog "not responding" opened, declined to kill immedietaly
Comment 11 Caolan McNamara 2011-02-09 11:45:24 EST
This one baffles me, crash is in drawing the progress bar, but the theme is a standard one so its not simply that, might be due to an update while running, but #9 rules that out so leaves me with a heisenbug where the real cause is likely something totally unrelated to the final point of crash :-(

If you still have the .xls which *might* have triggered this feel free to attach it here and I'll have a last-ditch import of it under valgrind to see if its anyway related.

Note You need to log in before you can comment on or make changes to this bug.