# editors/libreoffice exits with signal 11



## byrnejb (Dec 16, 2021)

Following the most recent pkg upgrade a number of applications simply stopped working and some produce core dumps when started.  The one that is causing the most inconvenience is libreoffice.

I infer that the problem lies not in Libreoffice itself but in some sort of necessary system library as reverting to the previous package does not cure the problem.  It fails with the same signal 11.

 Has anyone else  run into this or am I under some sort of dark cloud WRT FreeBSD.  Recently it seems that each upgrade breaks something that I use every day.   Is there a workaround?


----------



## eternal_noob (Dec 16, 2021)

Signal 11 is a "Segmentation violation", i.e. invalid memory reference. Maybe faulty RAM?


----------



## CuatroTorres (Dec 16, 2021)

I don't mean to be rude but ... what the hell? seems like the typical linuxist response throwing balls out. Blaming hw failure is the last thing to do, still after an update and assuming they worked normally.









						Alternative for strace on AMD64
					

Hi there I've seen that strace over ports seems not available for. Is there an alternative to debug applications? Currently I couldn't connect via ODBC to my PostgreSQL 9 databases. Last week my Apache HTTPs has crashed and I needed several time to debug and find out more about the error and...




					forums.freebsd.org


----------



## eternal_noob (Dec 16, 2021)

byrnejb said:


> Recently it seems that each upgrade breaks something





CuatroTorres said:


> Blaming hw failure is the last thing to do


So do you think it's normal behaviour that each upgrade breaks something?



CuatroTorres said:


> typical linuxist response throwing balls out






I just said that a "invalid memory reference" MAY be the result of faulty RAM. Not that this is the case.


----------



## CuatroTorres (Dec 16, 2021)

That needs more information, it doesn't indicate what's broken, it can be a bad setup or extreme setup.

In any case: memtest86+ or memtester.


----------



## Alain De Vos (Dec 16, 2021)

For me upgrades never break anything.
Have a look when applications start to dump core. 
If it's one, that can happen, ie a glitch in the matrix.
More than one or hardware failure or you have given the system bad instructions.


----------



## CuatroTorres (Dec 16, 2021)

Just shooting into the air, related to D-bus:






						228001 – devel/dbus: Applications segfault due to missing machine-id after package install
					






					bugs.freebsd.org


----------



## byrnejb (Dec 16, 2021)

There was an update to `knetwalk` this morning which cured the core dump problem which started after yesterday' upgrade.  Libreoffice still fails.  However, I installed Apache OpenOffice as a work-around and that runs fine.  

This system is my main workstation/development/testing host.  At the moment I have a Poudriere build going and I am upgrading an IOCage jail.  If there was a memory problem then I think that I would see other evidence besides LO's failure to start..

DBUS is enabled.

```
grep -i dbus /etc/rc.conf
dbus_enable="YES"
```

The previous problems that I have encountered have never been caused by a hardware issue.  Some of them have been causes by arbitrary changes to the pkg of which I was unaware.  Some of them have been caused by changes made to the pkg options of which I was unaware.  And some of them have been actual bugs.

However, from the perspectives of functionality and productivity these all amount to the same thing.  A loss of time trying to determine why something that worked fine earlier today does not work at all, or produces different results, following a pkg upgrade.  I can afford to have these mini-crises on my desktop, which I why I update there first.  But these experiences are the reason why many people who get a system running the way that meets their needs just leave it alone, security problems notwithstanding.


----------



## CuatroTorres (Dec 16, 2021)

Abiword and Gnumeric are good options if you don't need the full suite. They are also lightweight and don't depend on Java.


----------



## covacat (Dec 16, 2021)

try running it with a new user
sometines saved settings cause problems
if another user works you can try to delete saved settings


----------



## byrnejb (Dec 16, 2021)

Same problem occurs with a new user.


----------



## _martin (Dec 16, 2021)

While you could get SIGSEGV (segmentation fault) when using a bad memory I would not start troubleshooting there. That scenario is really less likely to occur. As you are experiencing this issue with more programs more likely than not it will be caused by some library that few programs depend on. It could be that you upgraded the lib and didn't recompile the program. Or you mixed and matched compiled ports and binary packages.

It doesn't make sense to guess. For this exact problem you have core dumps (dump of the running program).  Depending on your setup you may already have them. LibreOffice is big, really big. Don't expect you'll get somebody debugging it here (though nights are long here on the northern hemisphere  ).

Open a terminal and run this command: `ulimit -c unlimited`. Verify you don't have any core files in the home directory already. Start the office from command line (or any other program that you experienced crash) and trigger the crash. You should see the core file in the current working directory (name of the file will be  ${progname}.core).

Once you have it install the gdb from ports if you don't have it yet. Run these commands and share the output of them:

```
gdb /path/to/program/you/were/running /path/to/$program.core
bt
```
Where `bt` will be the output of the gdb command.


----------



## Voltaire (Dec 17, 2021)

I've been using a FreeBSD system for four years and haven't really had that an update caused issues. With two exceptions:
1) Creating an encrypted zip file via the command line suddenly stopped working correctly (is currently fixed in 12.3)
2) The latest LibreOffice takes extremely long to open. Gimp and other heavy apps open many times faster. I have an old i3 dual core and what I see in Conky is that the 4 threads alternately load almost 100% when LibreOffice opens. Although I wouldn't expect it to take that much CPU to open. The load over several threads should be divided instead of fueling heavily on one of the 4 threads.

A few months ago, LibreOffice opened a lot faster. Anyone else noticing that LibreOffice takes a lot of time to open?


----------



## Alain De Vos (Dec 17, 2021)

An alternative is using calligra.


----------



## Voltaire (Dec 17, 2021)

Alain De Vos said:


> An alternative is using calligra.


Calligra, Abiword and OpenOffice are not on the same level as LibreOffice in my opinion. They have noticeably fewer features, less compatibility with the real MS Office. And they are not as actively developed as LibreOffice. 

I would recommend WPS Office if you are looking for a powerful and compatible replacement for LibreOffice or MS Office: WPS Office for FreeBSD


----------



## grahamperrin@ (Dec 18, 2021)

Cross-reference FreeBSD bug 260472 – editors/libreoffice fails to start after upgrade, where a version is given.



byrnejb said:


> pkg



Latest or quarterly?

`pkg -vv | grep -e url -e enabled`

No problem here with 7.2.4.1_1 (from latest) on FreeBSD 12.3-RELEASE:


----------



## grahamperrin@ (Dec 18, 2021)

Off-topic from LibreOffice



byrnejb said:


> … arbitrary



I doubt it.



byrnejb said:


> changes to the pkg of which I was unaware. …  changes made to the pkg options of which I was unaware. … mini-crises …



If output from `pkg upgrade` includes a port that's essential to you, then – to minimise the risk of a crisis – you should see what's changed before deciding whether to allow the change.

FreshPorts is our friend. For example:



byrnejb said:


> … an update to `knetwalk` …



<https://www.freshports.org/games/knetwalk/#history> there's the history of changes.

If the visible description of any change is insufficient for you to make a decision, then click to see details of the commit. For example:

<https://cgit.freebsd.org/ports/commit/?id=2c348825da717d6771688449161324e3864d0207>


----------



## grahamperrin@ (Dec 18, 2021)

byrnejb

`strings ~/.config/libreoffice/4/user/uno_packages/cache/registry/com.sun.star.comp.deployment.component.PackageRegistryBackend/common.rdb | grep oxt`

Is anything found?

Sorry, scrub that; I forgot,



byrnejb said:


> Same problem occurs with a new user.






Voltaire said:


> … The latest LibreOffice



Which version, exactly?

Which version of FreeBSD?

UFS or ZFS?



> takes extremely long to open. … old i3 dual core and what I see in Conky is that the 4 threads alternately load almost 100% when LibreOffice opens. … The load over several threads should be divided instead of fueling heavily on one of the 4 threads.



I don't see an imbalance. A fairly even spread over these four: 



Core i7-3520M CPU @ 2.90GHz <https://bsd-hardware.info/?probe=045ffeb9b3#cpu:intel-6-58-9-core-i7-3520m>



> A few months ago, LibreOffice opened a lot faster. Anyone else noticing that LibreOffice takes a lot of time to open?



I haven't noticed a slowdown of LibreOffice with latest on CURRENT. That said, eight months ago I wasn't using L2ARC …


----------



## byrnejb (Dec 21, 2021)

FreeBSd-12.2p11 root on ZFS
LO-7.2.1.2

The maintainers feel that my problems are caused by a Linux package.  I cannot see how that is the case.  Only packages from the FreeBSD quarterly repository are installed  on this system; excepting only those that are repackaged locally using Poudriere because I need different options than those provided.

These are the only packages that I can easily identify as being linux:

```
pkg info -x linux
linux_base-c7-7.9.2009
linuxlibertine-g-20120116_2
syslinux-6.03
```

Now I added `linux_base-c7` AFTER LibreOffice failed to start because the initial failure made reference to libraries that I only found in that pkg.  Installing it had no effect on LO and removing it likewise did not change anything.

`Linuxlibertine-g` is a font.  And Libreoffice has it as a dependency.

`syslinux` is required by `unetbootin` which in turn is required by several qt5 packages.

The system I run LO on uses an NVidia driver (`nvidia-driver-390-390`).  If I had to guess I would say that this might be contributing to the problem.

I reinstalled earlier versions of LO from the cache and these fail to start as well.  Thus, the indication is that some library that LO depends upon has been 'improved'.

'Abitrary' is perhaps the wrong word. 'Needless' is more in keeping with the sentiment I wished to convey. 

 However, OpenOffice runs fine so I have switched to that.


----------



## grahamperrin@ (Dec 21, 2021)

byrnejb said:


> … Thus, the indication is that some library that LO depends upon has been 'improved'. …



I shouldn't draw that conclusion in your case.

Create, activate and boot a new boot environment. Then at a console e.g. ttyv1 (without attempting to use the desktop environment):

1. `pkg upgrade --force`
2. restart the OS.

pkg-upgrade(8)


----------



## Voltaire (Dec 22, 2021)

> Which version, exactly?
> 
> Which version of FreeBSD?
> 
> UFS or ZFS?


Version 7.2.1.2
ZFS
FreeBSD 12.2


----------



## Voltaire (Dec 23, 2021)

I did additional tests today. LibreOffice takes exactly *54 seconds* to open on my system. (Intel i3-3240 + EVO 850 SSD + 4GB ddr3)

I also tested some other apps and none of them takes longer than 10 seconds to open on this system. These are the boot times of other apps: Firefox: *2s*, Abiword: *7s*, Chromium: *1s*, GIMP: *5s*, Audacity: *4s*

Is LibreOffice really that heavy compared to other software?


----------



## grahamperrin@ (Dec 23, 2021)

Voltaire said:


> … *54 seconds* to open …



Here: 

first run around forty-three seconds
subsequent runs less than seven seconds.



Spoiler: ZFS stats and timings





```
% uname -KU
1400043 1400043
% zfs-stats -L

------------------------------------------------------------------------
ZFS Subsystem Report                            Thu Dec 23 09:48:07 2021
------------------------------------------------------------------------

L2 ARC Summary: (DEGRADED)
        Low Memory Aborts:                      2.18    k
        Free on Write:                          16.05   k
        R/W Clashes:                            18
        Bad Checksums:                          137.32  k
        IO Errors:                              0

L2 ARC Size: (Adaptive)                         39.44   GiB
        Decompressed Data Size:                 110.35  GiB
        Compression Factor:                     2.80
        Header Size:                    0.14%   153.20  MiB

L2 ARC Evicts:
        Lock Retries:                           41
        Upon Reading:                           3

L2 ARC Breakdown:                               6.35    m
        Hit Ratio:                      87.14%  5.54    m
        Miss Ratio:                     12.86%  816.92  k
        Feeds:                                  165.07  k

L2 ARC Writes:
        Writes Sent:                    100.00% 35.08   k

------------------------------------------------------------------------

% which libreoffice
/usr/local/bin/libreoffice
% time /usr/local/bin/libreoffice
4.274u 0.859s 0:42.91 11.9%     5+5419k 9753+150io 8976pf+0w
% time /usr/local/bin/libreoffice
4.133u 1.169s 0:06.36 83.1%     5+18349k 0+150io 28pf+0w
% time /usr/local/bin/libreoffice
4.094u 1.273s 0:06.60 81.2%     5+1687k 1+150io 28pf+0w
% zfs-stats -L

------------------------------------------------------------------------
ZFS Subsystem Report                            Thu Dec 23 09:49:47 2021
------------------------------------------------------------------------

L2 ARC Summary: (DEGRADED)
        Low Memory Aborts:                      2.18    k
        Free on Write:                          16.05   k
        R/W Clashes:                            18
        Bad Checksums:                          137.42  k
        IO Errors:                              0

L2 ARC Size: (Adaptive)                         39.44   GiB
        Decompressed Data Size:                 110.37  GiB
        Compression Factor:                     2.80
        Header Size:                    0.13%   152.35  MiB

L2 ARC Evicts:
        Lock Retries:                           41
        Upon Reading:                           3

L2 ARC Breakdown:                               6.36    m
        Hit Ratio:                      87.15%  5.55    m
        Miss Ratio:                     12.85%  817.50  k
        Feeds:                                  165.17  k

L2 ARC Writes:
        Writes Sent:                    100.00% 35.13   k

------------------------------------------------------------------------

% date ; uptime
Thu 23 Dec 2021 09:50:03 GMT
 9:50a.m.  up 1 day, 22:59, 7 users, load averages: 0.39, 1.05, 1.24
%
```






Voltaire said:


> … Is LibreOffice really that heavy compared to other software?



I believe so. From 2004 documentation for _OpenOffice_: 



<https://ask.libreoffice.org/t/libreoffice-quickstarter/30753/4>: 



> QuickStart was removed from LibreOffice for Linux. …



I guess that it's also no longer a feature of the port to FreeBSD.


----------



## Voltaire (Dec 23, 2021)

> % time /usr/local/bin/libreoffice
> 4.274u 0.859s 0:42.91 11.9%     5+5419k 9753+150io 8976pf+0w
> % time /usr/local/bin/libreoffice
> 4.094u 1.273s 0:06.60 81.2%     5+1687k 1+150io 28pf+0w
> ...


It takes me the same amount of time every time, even if I start and close the app several times in succession.
Furthermore, I also get a different output when I run your command `time /usr/local/bin/libreoffice` with sh or with bash:
`$ time /usr/local/bin/libreoffice
libGL error: MESA-LOADER: failed to retrieve device information
real 1m16.990s
user 0m28.669s
sys 0m35.135s`


----------



## grahamperrin@ (Dec 23, 2021)

Voltaire thanks, this aspect is likely to run into a few posts. Would you like to spin off to a new topic? I'll follow with a move of my content.

For things to be clear here when the *exit (signal 11)* issue is resolved. Thanks.


----------



## byrnejb (Dec 24, 2021)

I followed the suggestion to move to a new boot environment and do a `pkg upgrade --force`.  The *exit(signal 11)* issue was not resolved by this.

I am now upgrading FreeBSD to 12.3 in the same boot environment to see if that has any effect.  Doubtful, but nothing else works.


----------



## byrnejb (Dec 24, 2021)

The upgrade to FreeBSd-12.3 did not cure the problem either.  My suspicions are that this may have something to do with the fact that this host has an NVidia card( GT730).  In any case LO does not work and Apache OpenOffice does.  Unless and until this problem is dealt with in a future update I will use OO instead.


----------



## byrnejb (Dec 24, 2021)

_martin said:


> . . .
> Open a terminal and run this command: `ulimit -c unlimited`. Verify you don't have any core files in the home directory already. Start the office from command line (or any other program that you experienced crash) and trigger the crash. You should see the core file in the current working directory (name of the file will be  ${progname}.core).
> 
> Once you have it install the gdb from ports if you don't have it yet. Run these commands and share the output of them:
> ...




```
gdb /usr/local/lib/libreoffice/program/soffice.bin \
    ./soffice.bin.core
GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.2".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/lib/libreoffice/program/soffice.bin...
(No debugging symbols found in /usr/local/lib/libreoffice/program/soffice.bin)
[New LWP 100727]
[New LWP 101118]
[New LWP 100620]
Core was generated by `/usr/local/lib/libreoffice/program/soffice.bin --splash-pipe=5'.
Program terminated with signal SIGABRT, Aborted.
Sent by thr_kill() from pid 12993 and user 0.
#0  0x0000000800561c2a in thr_kill () from /lib/libc.so.7
--Type <RET> for more, q to quit, c to continue without paging--
[Current thread is 1 (LWP 100727)]
(gdb)
(gdb)
(gdb)
```


----------



## _martin (Dec 24, 2021)

byrnejb Are you running the office as root? I wonder what the pid 12993 was during the crash. Please share the output of these gdb commands: `bt` and `info threads`.


----------



## Voltaire (Dec 26, 2021)

> Voltaire thanks, this aspect is likely to run into a few posts. Would you like to spin off to a new topic? I'll follow with a move of my content.


Today I did a factory reset of LibreOffice as it sometimes fixes the slow boot time issue. But it has had no impact.

Whether I want to continue with this topic depends on whether you think 54s start time is normal for my hardware, where most apps boot in less than 10s. It could be that LibreOffice is so heavy on all platforms that it will take around 54s to boot on my hardware. In that case, I see no reason to go further into it. But I also know that it used to open a lot faster (months ago). Is the 54s start time normal behavior for the current version or not?


----------



## byrnejb (Dec 29, 2021)

I decided to rebuild LibreOffice on my system using Poudriere and it failed (1 failed / 404 pkgs built):


```
. . .
cp /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/extras/source/gallery/share/gallery_names.ulf /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/workdir/Gallery/backgrounds/backgrounds.ulf
cp -P -f /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/workdir/Gallery/backgrounds/backgrounds.sdg /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/instdir/share/gallery/backgrounds.sdg && /usr/bin/touch -hr /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/workdir/Gallery/backgrounds/backgrounds.sdg /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/instdir/share/gallery/backgrounds.sdg
cp -P -f /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/workdir/Gallery/backgrounds/backgrounds.sdv /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/instdir/share/gallery/backgrounds.sdv && /usr/bin/touch -hr /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/workdir/Gallery/backgrounds/backgrounds.sdv /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/instdir/share/gallery/backgrounds.sdv
cp -P -f /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/workdir/Gallery/backgrounds/backgrounds.thm /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/instdir/share/gallery/backgrounds.thm && /usr/bin/touch -hr /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/workdir/Gallery/backgrounds/backgrounds.thm /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/instdir/share/gallery/backgrounds.thm
[build STR] backgrounds/backgrounds
cp -f /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/extras/source/gallery/backgrounds/backgrounds.str /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/workdir/Gallery/backgrounds/backgrounds.str && /usr/local/bin/python3.8 /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/solenv/bin/desktop-translate.py --ext "str" --key "name" -d /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/workdir/Gallery/backgrounds /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/workdir/Gallery/backgrounds/backgrounds.ulf
cp -P -f /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/workdir/Gallery/backgrounds/backgrounds.str /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/instdir/share/gallery/backgrounds.str && /usr/bin/touch -hr /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/workdir/Gallery/backgrounds/backgrounds.str /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/instdir/share/gallery/backgrounds.str
[build PKG] Gallery/backgrounds
rm -f /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/workdir/Package/Gallery/backgrounds.filelist && \
mv /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/workdir/Package/Gallery/backgrounds.filelist.tmp /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/workdir/Package/Gallery/backgrounds.filelist
touch /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1/workdir/Gallery/backgrounds.final
[build BIN] extras
S=/wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1 && I=$S/instdir && W=$S/workdir &&  mkdir -p $W/Module/nonl10n/ && touch $W/Module/nonl10n/extras
[build MOD] extras
S=/wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-7.2.4.1 && I=$S/instdir && W=$S/workdir &&  mkdir -p $W/Module/ && touch $W/Module/extras
=>> Killing runaway build after 7200 seconds with no output
=>> Cleaning up wrkdir
===>  Cleaning for libreoffice-7.2.4.1_1
build of editors/libreoffice | libreoffice-7.2.4.1_1 ended at Sat Dec 25 01:21:02 EST 2021
build time: 02:51:41
!!! build failure encountered !!!
Killed
```

Since this build ran in an jail it seems unlikely that this can be attributed to some spurious software instlled on the host system.


----------



## grahamperrin@ (Dec 29, 2021)

byrnejb said:


> `… Killing runaway build after 7200 seconds with no output`



`grep -C 2 runaway /usr/local/etc/poudriere.conf.sample`


----------

