Description: After updating to 5.4.5.1 I can not open or save documents in LO. - If I double-click an .odt the logo of LO can be seen for a second, than it disappears and nothing happens - If I start LO and try to open from inside the program via "open File" nothing happens - If I try to start one of the last opened files with double-click nothing happens - If I open a Template all is fine until I want to save it. Then it says "object does not exist; file does not exist" Steps to Reproduce: 1. I reinstalled LO via Synaptic 2. I overwrote ~/.config/libreoffice/... from a three weeks old backup 3. I created a new user and tried with that user 4. I started LO in recovery mode Actual Results: Nothing of the above helped to solve the problem Expected Results: should bee able to open files Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Do you use kde? If yes, it might be a dup of tdf#98776 You can try workaround described here: https://bugs.documentfoundation.org/show_bug.cgi?id=98776#c32
Could you please paste the info from Help - About LibreOffice? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the information has been provided
Here the data from LO Help About LO Version: 5.4.5.1 Build-ID: 1:5.4.5-0ubuntu0.17.10.1 CPU-Threads: 4; BS: unknown; UI-Render: Standard; VCL: gtk3; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
Sorry, but the reset of the LO profile did do nothing (as expected). Otherwise the backup of */.config/libreoffice/... or the new user that I had tried before I reported the bug should have solved the problem. I have tried to start via terminal. LO starts and shows the same behavior with the bug. There are no outputs at the terminal that say that something is not working properly.
Would it be possible you attach a backtrace? (see https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace)
Created attachment 140187 [details] gdbtrace.log 1. Started LO 2. Tried to open an existing file 3. Opened a template and tried to 'save as' 4. Closed LO
Badfully there's no stack trace here. For the test, you can try with other rendering, by launch LO from terminal but with this command before: export SAL_USE_VCLPLUGIN=gtk or export SAL_USE_VCLPLUGIN=kde4 or export SAL_USE_VCLPLUGIN=gen
Created attachment 140227 [details] gdbtrace_gtk.log After $ export SAL_USE_VCLPLUGIN=gtk and $ soffice --backtrace LO started and i could open and save Documents. What has happened? What does export SAL_USE_VCLPLUGIN=gtk do? Will i have to do this after every reboot or is there an option to fix the problem? I also have been searching for an solution. In syslog i found this: Feb 27 17:52:03 ~ kernel: audit: type=1400 audit(1519750323.851:32): apparmor="DENIED" operation="open" profile="libreoffice-oopslash" name="/run/user/1000/gdm/Xauthority" pid=8891 comm="oosplash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 Feb 27 17:52:03 ~ kernel: audit: type=1400 audit(1519750323.860:33): apparmor="DENIED" operation="open" profile="libreoffice-oopslash" name="/sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/queue/rotational" pid=8891 comm="oosplash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 Feb 27 17:52:04 ~ kernel: audit: type=1400 audit(1519750324.052:34): apparmor="DENIED" operation="open" profile="libreoffice-oopslash" name="/sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/queue/rotational" pid=8891 comm="oosplash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 Feb 27 17:52:04 ~ kernel: audit: type=1400 audit(1519750324.320:35): apparmor="DENIED" operation="open" profile="libreoffice-soffice" name="/usr/share/nvidia-340/nvidia-application-profiles-340.104-rc" pid=8915 comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 Feb 27 17:52:04 ~ kernel: audit: type=1400 audit(1519750324.337:36): apparmor="DENIED" operation="open" profile="libreoffice-soffice" name="/usr/share/nvidia-340/nvidia-application-profiles-340.104-rc" pid=8915 comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 Feb 27 17:52:04 ~ kernel: audit: type=1400 audit(1519750324.354:37): apparmor="DENIED" operation="open" profile="libreoffice-soffice" name="/proc/modules" pid=8915 comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 Feb 27 17:52:04 ~ kernel: audit: type=1400 audit(1519750324.354:38): apparmor="DENIED" operation="open" profile="libreoffice-soffice" name="/proc/driver/nvidia/params" pid=8915 comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 Feb 27 17:52:04 ~ kernel: audit: type=1400 audit(1519750324.354:39): apparmor="DENIED" operation="open" profile="libreoffice-soffice" name="/dev/nvidiactl" pid=8915 comm="soffice.bin" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=0 Feb 27 17:52:04 ~ kernel: audit: type=1400 audit(1519750324.811:40): apparmor="DENIED" operation="open" profile="libreoffice-soffice" name="/home/~/.local/share/fonts/CALIBRIB.TTF" pid=8910 comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 Feb 27 17:52:04 ~ kernel: audit: type=1400 audit(1519750324.811:41): apparmor="DENIED" operation="open" profile="libreoffice-soffice" name="/home/~/.local/share/fonts/CALIBRIB.TTF" pid=8910 comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 Could this be the reason?
This command allows to use a different rendering. By default, you use gtk3 libs, with this command you'll use gtk libs. You can add the export command in your ~/.bashrc or equivalent. Of course, it's just a workaround.
To change the rendering helps (for the moment), but it will change the rendering of the hole session with all other progs. Would'nt it be better to change only the behavior of LO? Or change the behavior of apparmor corresponding to LO? And why changes apparmor its behavior without having told to do so?
It's a Ubuntu bug that is fixed: https://bugs.documentfoundation.org/show_bug.cgi?id=98776#c40