Bug 798520 - [abrt] libreoffice-core- cppu::throwException -> getTypeName: SIGSEGV
[abrt] libreoffice-core- cppu::throwException -> getTypeName: ...
Product: Fedora
Classification: Fedora
Component: libreoffice (Show other bugs)
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Stephan Bergmann
Fedora Extras Quality Assurance
: 1157214 1192939 1252198 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2012-02-29 01:55 EST by Jindrich Novy
Modified: 2015-08-31 08:04 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-03-07 15:48:13 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: dso_list (20.66 KB, text/plain)
2012-02-29 01:55 EST, Jindrich Novy
no flags Details
File: backtrace (225.04 KB, text/plain)
2012-02-29 01:55 EST, Jindrich Novy
no flags Details
File: maps (77.69 KB, text/plain)
2012-02-29 01:55 EST, Jindrich Novy
no flags Details
LibreOffice "Fatal error" window (15.23 KB, image/png)
2015-08-31 08:04 EDT, Diego
no flags Details

  None (edit)
Description Jindrich Novy 2012-02-29 01:55:37 EST
libreport version: 2.0.8
abrt_version:   2.0.7
backtrace_rating: 4
cmdline:        /usr/lib64/libreoffice/program/soffice.bin --calc obchody_celkem_2011_fifo.csv --splash-pipe=8
comment:        Closing libreoffice spreadsheet
crash_function: getTypeName
executable:     /usr/lib64/libreoffice/program/soffice.bin
kernel:         3.2.7-1.fc16.x86_64
pid:            28019
reason:         Process /usr/lib64/libreoffice/program/soffice.bin was killed by signal 11 (SIGSEGV)
smolt_data:     Unable to save UUID to /etc/smolt/hw-uuid.  Please run once as root.
time:           St 29. únor 2012, 07:38:35 CET
uid:            501
username:       jnovy

backtrace:      Text file, 230444 bytes
dso_list:       Text file, 21157 bytes
maps:           Text file, 79552 bytes

:'LESSOPEN=||/usr/bin/lesspipe.sh %s'
:'module=() {  eval `/usr/bin/modulecmd bash $*`\n}'

:Feb 29 07:38:35 pucmeloud kernel: [91211.417282] soffice.bin[28019]: segfault at 8 ip 00000031f062250c sp 00007fff1b7281c0 error 4 in libuno_cppu.so.3[31f0600000+3a000]
:Feb 29 07:38:37 pucmeloud abrt[28221]: Saved core dump of pid 28019 (/usr/lib64/libreoffice/program/soffice.bin) to /var/spool/abrt/ccpp-2012-02-29-07:38:35-28019 (137437184 bytes)
Comment 1 Jindrich Novy 2012-02-29 01:55:42 EST
Created attachment 566470 [details]
File: dso_list
Comment 2 Jindrich Novy 2012-02-29 01:55:44 EST
Created attachment 566471 [details]
File: backtrace
Comment 3 Jindrich Novy 2012-02-29 01:55:47 EST
Created attachment 566472 [details]
File: maps
Comment 4 Caolan McNamara 2012-02-29 05:42:55 EST
reproducible ?
Comment 5 Jindrich Novy 2012-02-29 05:55:59 EST
Seems to be a race condition of some kind. Not always reproducible.
Comment 6 Caolan McNamara 2012-03-05 09:20:29 EST
what are the circumstances under which is is sometimes reproducible ?, is there a certain document involved or does it appear to be unrelated to any given .ods/.xls ?
Comment 7 Jindrich Novy 2012-03-06 04:19:20 EST
What I was doing at the time was that I opened a CSV file and saved is as XLS. Then closed libreoffice.
Comment 8 Eike Rathke 2012-03-07 10:46:09 EST
I wasn't able to reproduce using libreoffice-

From the attached trace it seems SfxMedium wanted to remove the lockfile for the .csv file and already ucbhelper::Content::getPropertyValue attempted to read from the woods..
Comment 9 Caolan McNamara 2012-03-07 15:48:13 EST
doesn't look like it was any exotic file location, like a temp evolution file. so we're basically clueless here, right ? :-(
Comment 10 Stephan Bergmann 2014-10-27 04:48:18 EDT
*** Bug 1157214 has been marked as a duplicate of this bug. ***
Comment 11 Stephan Bergmann 2014-10-27 05:02:11 EDT
This still leaves me clueless.  Apparently cppu::throwException's

  Mapping uno2cpp(Environment(UNO_LB_UNO), Environment::getCurrent());

calls the Mapping ctor -> uno_getMapping with a null pTo, i.e., the call to

  getCurrent(rtl::OUString const & typeName = rtl::OUString(CPPU_STRINGIFY(CPPU_ENV)))

must have returned null.  Now, even if uno_getCurrentEnvironment added some non-empty currPurpose to pTypeName = "gcc3":

* uno_getEnvironment must have called uno_direct_getEnvironment unmodified, as UNO_ENV_SUBST: is not a set env var.

* For uno_direct_getEnvironment to return with a null *ppEnv, it must call initDefaultEnvironment.

* initDefaultEnvironment extracts "gcc3" from rEnvDcp (ignoring any purpose potentially added in uno_getCurrentEnvironment above), and must go into the else branch ("gcc3" != "uno"), and the call to loadEnv must fail.

* loadEnv("gcc3_uno") loads libgcc3_uno.so relative to libuno_cppu.so.3, and that library is indeed loaded, so unclear to me where something went wrong.
Comment 12 Cristian Ciupitu 2015-04-06 22:19:51 EDT
I'm using libreoffice-calc- and according to ABRT this bug occurred when I was opening a CSV file while a XLSX was already opened.
Comment 13 Stephan Bergmann 2015-04-07 03:46:40 EDT
...but I assume you're not able to reproduce, are you?
Comment 14 Cristian Ciupitu 2015-04-07 18:11:43 EDT
No, unfortunately I have no idea how to reproduce it.
Comment 15 Stephan Bergmann 2015-08-11 05:03:40 EDT
*** Bug 1252198 has been marked as a duplicate of this bug. ***
Comment 16 Stephan Bergmann 2015-08-11 05:30:29 EDT
*** Bug 1192939 has been marked as a duplicate of this bug. ***
Comment 17 Diego 2015-08-31 08:02:51 EDT
Ok, I think I've found a way to reproduce this and the crash is due to the file being deleted while LibreOffice has it open. This is how I reproduce it in Fedora 21 with Firefox under KDE using Ark:
1) go here: https://www.wholesale.telecomitalia.com/it/catalogo/-/catalogo_aggregator/article/31258?p_r_p_564233524_activePortletId=&_2_WAR_nwscatalogoportlet_activePortlet=false&_2_WAR_nwscatalogoportlet_tab=Coperture&p_r_p_564233524_categoryId=31260&p_r_p_564233524_isList=true
2) download "ADSL su DSLAM Ethernet da Centrale e da Armadio tutte le velocità (file pianificato)" --- other files should crash too, but I've tested with this one
3) in the Firefox dialog select "Open with Ark" and press "OK"
4) click on the file in the just opened Ark window
5) Ark should extract the file in "/tmp/kde-<user>/ark<something>/Copertura pianificata ADSL su DSLAM ETHERNET da Centrale e da Armadio 28-ago-2015.xls" and LibreOffice should open the file
6) close Ark window, the file "/tmp/kde-<user>/ark<something>/Copertura pianificata ADSL su DSLAM ETHERNET da Centrale e da Armadio 28-ago-2015.xls"  and the "ark<something>" directory should get deleted
7) go back to the LibreOffice window and click "File", a "Fatal error" window saying "cannot get environments" should appear; clicking on "OK" will close LibreOffice.

So the problem is caused by the file being deleted while LibreOffice has it open. Don't know if it should be considered a bug, anyhow that's how to always reproduce the problem.
Comment 18 Diego 2015-08-31 08:04:02 EDT
Created attachment 1068622 [details]
LibreOffice "Fatal error" window

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