editors/libreoffice exits with signal 11

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?
 
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.

 
Recently it seems that each upgrade breaks something
Blaming hw failure is the last thing to do
So do you think it's normal behaviour that each upgrade breaks something?

typical linuxist response throwing balls out
FEzSy3HXMAQ20gc.jpeg

I just said that a "invalid memory reference" MAY be the result of faulty RAM. Not that this is the case.
 
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.
 
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.
 
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.
Code:
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.
 
Abiword and Gnumeric are good options if you don't need the full suite. They are also lightweight and don't depend on Java.
 
try running it with a new user
sometines saved settings cause problems
if another user works you can try to delete saved settings
 
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:
Code:
gdb /path/to/program/you/were/running /path/to/$program.core
bt
Where bt will be the output of the gdb command.
 
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?
 
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
 
Off-topic from LibreOffice

… arbitrary

I doubt it.

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:

… 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>
 
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,

Same problem occurs with a new user.



… 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:

1639846802831.png

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 …
 
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:
Code:
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.
 
… 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)
 
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?
 
54 seconds to open …

Here:
  1. first run around forty-three seconds
  2. subsequent runs less than seven seconds.
Code:
% 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
%

… Is LibreOffice really that heavy compared to other software?

I believe so. From 2004 documentation for OpenOffice:

1640253609184.png

<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.
 
% 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

Here:

  1. first run around forty-three seconds
  2. subsequent runs less than seven seconds.
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
 
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.
 
Back
Top