Home | News | Download | Packages | Forum | Wiki | Github

[SOLVED] LibreOffice crashes silently on startup


#22

I have done this in the past as well, on a few strange Debian derivatives. I do not think it will work in this case, because the issue lies in how LibreOffice is run, not necessarily how it is installed.

After reviewing the information we’ve all managed to compile in this thread, I refined my Google search queries a bit and tried approaching the problem from a narrower angle.

I stumbled upon this thread, the gist of which was to run LibreOffice thusly: SAL_USE_VCLPLUGIN=gtk libreoffice --writer. This solved the issue for me!

Now we have two things: a solution, and the knowledge that this issue doesn’t seem specific to Void. Or at least, the issue is not something that originates from the repositories. My next goal is to determine how other distros avoid this problem. There must be an intelligent way to determine how to set this variable so that LO does not crash.

There appears to be more information available here which details a permanent solution, but the files referenced by that page don’t exist on my system, so I’ll give it a rest for now… I am happy to have LibreOffice working for the moment. I will return to the problem tomorrow.

@bluemoon confirm this works for you?

EDIT: It was discovered post-haste that booting with stack_guard_gap=1 is necessary to solve the issue completely. This can be done temporarily at the GRUB prompt, or permanently by editing /etc/default/grub.


#23

Unfortunately not. The only difference is that it’s not crashing immediately. Writer starts, I can type a bit, but then bang. :frowning:


#24

You’re right! I was so excited to see LibreOffice opening properly that I neglected to test further. Indeed, it crashes after a single keystroke.

However, after some more searching I have discovered this post that suggests booting with stack_guard_gap=1. This has solved the issue completely for me!

Does this work for you?

@WantToHelp @jacmoe Could you both please post output of echo $SAL_USE_VCLPLUGIN and also cat /proc/cmdline? I am interested to see what (if anything) is different about your system(s) versus ours. @Protokol if LO is still working for you, I’d appreciate this information about your system as well.

Thanks everybody, we’ve almost got this thing in the bag!


(Jacob Moen) #25
[jacmoe@jacmoe-pc ~]$ echo $SAL_USE_VCLPLUGIN 
kde4
[jacmoe@jacmoe-pc ~]$ cat  /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.12.12_1 root=UUID=8e61e9a0-e45f-4eba-bd98-9c8f29918a4e ro loglevel=4 slub_debug=P page_poison=1
[jacmoe@jacmoe-pc ~]$

#26
[void@void ~]$ echo $SAL_USE_VCLPLUGIN

[void@void ~]$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.13.1_1 root=UUID=b104420a-4edf-4214-9def-5125b1d88305 ro loglevel=4 slub_debug=P page_poison=1 console=tty2
[void@void ~]$

#27

Yes, it works. Thanks! But I just used it to disable java and then switched back to default, because I don’t know the implications of stack_guard_gap=1. Without java everything is fine.

Edit:
Found an interesting article about the stack guard: https://lwn.net/Articles/725832/
So reducing the gap might not be such a good idea?


#28

@KeepBotting yes, LO still working great for me

~  echo $SAL_USE_VCLPLUGIN
gtk
~  cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.12.12_1 root=UUID=99e5651c-576f-4272-9183-e204df7d7506 ro loglevel=4 slub_debug=P page_poison=1


#29

Glad to hear it. I’ve disabled Java as well. I’ll remove the boot option from my /etc/default/grub soon, unless I forget all about it :stuck_out_tongue:

I didn’t realize the stack guard was a security thing. I haven’t read that article yet but I’ll definitely skim it later to familiarize myself with the implications of altering the guard. At any rate it seems odd that a distro like Void would have Java enabled in LibreOffice at all. Feels like it adds a lot of extra bloat to an already heavyweight program. And I’ve certainly never even used the feature.

Perhaps a proposal should be made to no longer use that build option by default, seems like it causes trouble.

Edit: I was curious why LO uses Java, and it appears as though portions of the program are still written in Java. Apparently it’s being phased out, and Java-based components are being rewritten but it’s an ongoing WIP. Wiki and forum thread.

I would say that dropping Java from Void’s LibreOffice package seems like a good idea. It would keep us on the forefront of development and encourage the rapid dispersal of LO’s dependency on Java, while only temporarily sacrificing a few nonessential features.


#30

Incredible! It fixes the issue!! :clap:


#31

Well, sadly I delete LibreOffice from my i686 Voidlinux system and now I can’t install it back :frowning: I’ve got an error : "this package is not available in the database"
so don’t delete it of your system because you may not be able to install it back through xbps-install or octo…


(Jacob Moen) #32

You probably have a good reason to be using i686 …

Can’t you just install LibreOffice manually, then?


#33

@Protokol A fix is in the works, see this issue. In the meantime you can build it yourself – ensure you either use the workaround detailed in this thread OR disable Java at compile time. Then you should be fine.

@jacmoe A reason, at least. Some of us just happen to own ancient hardware :stuck_out_tongue: it can be a fun project, coaxing stuff into running properly on architectures that others have largely abandoned.

Or, y’know, maybe I just bought a laptop in 2008 and have been too lazy to upgrade. That’s a possibility too :wink:


#34

I really like old machines. :older_woman:


#35

rpm2tgz ? In Void we have rpmextract

Just my opinion, but I prefer to download DEB archives instead of RPM.


#36

I just saw that a fix is coming https://github.com/voidlinux/void-packages/commit/ec483e187c1be4f81f18c5e3acdc4bdf651f7e02

I’ve got a 64 bits PC but I used to use my old Asus i686 laptop which is working great actually with only 2gb of ram and Void Inside.
As long I will find 32 bits systems and apps to run with it, I will continue
Thanks for all your comments

update : solved ! thanks the all team !