I have a student testing Mageia 5 (for the past week) and three times LibreOffice has stopped working. When trying to run it, it shows the splash screen and then immediately exits. This happens no matter how you try to run it. A reboot makes it work again. The machine is running at the msec secure level. Debuginfo packages are not installed, so a gdb trace doesn't give much info, but it ends with this: [New Thread 0xae691b40 (LWP 25189)] [Thread 0xae691b40 (LWP 25189) exited] [Thread 0xb463ab40 (LWP 25172) exited] [Inferior 1 (process 25167) exited with code 01] /usr/lib/libreoffice/program/gdbtrace:9: Error in sourced command file: No stack. No stack. I capture a strace log as well and will attach that. It doesn't have anything that looks obviously helpful for debugging this to me, but maybe you'll see something. Reproducible: Steps to Reproduce:
The strace log is 4.1 MB (213K compressed with xz -9). I can't attach it. Not sure what to do...
Please install the debuginfo and attach the GDB trace
Keywords: (none) => NEEDINFO
attach it compressed...
Whiteboard: (none) => MGA5TOO
Created attachment 6753 [details] ooffice --strace with a file to open
Oh yeah, 213K < 1000K :o) Strace log attached. It happened again this morning. Even with libreoffice-debuginfo installed, --backtrace gives nothing useful. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i686/libthread_db.so.1". [New Thread 0xb463ab40 (LWP 28284)] Detaching after fork from child process 28285. [New Thread 0xae7fbb40 (LWP 28298)] [Thread 0xae7fbb40 (LWP 28298) exited] [Thread 0xb463ab40 (LWP 28284) exited] [Inferior 1 (process 28023) exited with code 01] /usr/lib/libreoffice/program/gdbtrace:9: Error in sourced command file: No stack. Missing separate debuginfos, use: debuginfo-install [... list of packages ...] No stack.
Keywords: NEEDINFO => (none)
It seems like it may be a daily cron that's killing it. [root@B-STU81-P ~]# ls /etc/cron.daily/ 0anacron-timestamp* logrotate* mlocate.cron* rpm* google-chrome* makewhatis.cron* msec@ tmpwatch* There was readahead.cron in there too. I just uninstalled readahead to see if it's causing the problem. We'll see tomorrow. The only other one that seems likely to be a potential cause is msec.
No trace, no chocolate... You can rename /usr/lib/libreoffice/program/gdbtrace Also you'd better use "thread apply all bt full"
Ie: just run libreoffice from the terminal, suspend it fast enough, then run: gdb /usr/lib64/libreoffice/program/soffice.bin <pid_of_soffice> then type "continue" then once it has crashed, type "thread apply all bt full"
Though note that gdb will be useless if doesn't actually crash. Also, if you're using KDE, please try removing libreoffice-kde
From what I see in the strace log, I don't think it's technically crashing (like a SIGSEGV or SIBABRT or anything), so I don't know why it's exiting. Given that it isn't like this all the time (we're starting to think it is a daily cron job that breaks it), I doubt libreoffice-kde has anything to do with it, but if removing the readahead package and cron job doesn't prevent it from happening again, I'll try removing libreoffice-kde.
OK, I figured it was more likely to be msec. I cloned to another machine so I could play around with it. I narrowed it down to msecperms setting 1773 permissions on /tmp/ (normal is 1777). Toggling the "other" role's read permissions on /tmp does indeed break and fix LibreOffice. You should be able to reproduce this locally now.
Keywords: NEEDINFO => (none)Summary: libreoffice stops working after a day or so, a reboot fixes this => libreoffice doesn't work if /tmp is not world-readable
Well the higher you set the security level, the higher are the odds to break something...
Source RPM: libreoffice-4.4.2.2-4.mga5.src.rpm => libreoffice-4.4.2.2-4.mga5.src.rpm, msec
Sure, but a program shouldn't break just because it can't see a directory listing of the file names in /tmp. It's a perfectly valid change for msec to make.
Source RPM: libreoffice-4.4.2.2-4.mga5.src.rpm, msec => libreoffice-4.4.2.2-4.mga5.src.rpm
Version: Cauldron => 5
Please report this upstream
Thank you for having taken the needed time to report this issue! Did this bug get fixed? If so, please change it's status to RESOLVED - FIXED If it didn't, then we regret that we weren't able to fix it in Mageia 5. Mageia 5 has officially reached its End of Life on December 31st, 2017 https://blog.mageia.org/en/2017/11/07/mageia-5-eol-postponed/ It only continued to get important security updates since then, because we are waiting for a big Plasma5 update in Mageia 6, that'll fix many of the Mageia 5 => 6 upgrade issues. If you haven't seen that this bug got fixed, then please check whether this bug still exists in Mageia 6. If it does, then please change the Version (near the top, at the left) to "6". If you know it exists in Cauldron, then change Version to Cauldron. If you see it in both Cauldron and Mageia 6, then please set version to Cauldron and add MGA6TOO on the Whiteboard. Thanks, Marja (In reply to Thierry Vignaud from comment #14) > Please report this upstream @ David If this bug is still valid: please give the link to the upstream report
CC: (none) => marja11
Someone else will have to if they care about it.
Resolution: (none) => OLDStatus: NEW => RESOLVED