Frequent crashes of 4.1.8 on Linux, recovery non-functional

Issues with installing under all GNU/Linux Distributions
hman2
Posts: 63
Joined: Sun Nov 22, 2020 11:51 pm

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by hman2 »

Observation: For reasons unknown, it only crashes if you put the cursor in the blank line immediately above the table, and start adding newlines.

When you place the cursor in the other blank line (line 2), AOO will NOT crash, no matter how many newlines you add. The table will flow over to the next page, as it should, until at some point all of it rests on page 2.

If after that, you place the cursor into the blank line above the table and start adding more newlines, the table will line by line wrap onto page 3, as it should, but when it comes to the first first line of the table, AOO crashes.

So this is proof that there is something special about this blank line above the table. To find out whether some nonprinting characters or fields or whatever are located there, I switched display of them on, but there is nothing except the paragraph sign.
OpenOffice 4.18 on Linux Mint 18
John_Ha
Volunteer
Posts: 9583
Joined: Fri Sep 18, 2009 5:51 pm
Location: UK

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by John_Ha »

hman2 wrote:I have been working as a professional software tester (ISTQB) for more than a decade now, and I am in the industry for three. So you can rest assured that I know what I am doing. There is nothing in my setup that is out of the ordinary.
Excellent. You will therefore presumably agree it is a problem with your environment as other Mint users don't have problems with tables. Diagnosis is therefore required to identify the factor causing your problem.

Have you reset the user profile? See Resetting the user profile. It is essential you do this.
hman2 wrote:I have already tried without the "calculation" (which anyway was just a multiplication). Still crashes.
After resetting the profile try this file which just has a table and text.

Incidentally, I tried to reconstruct your scenario by opening your file. This created a temporary file C:\Users\John\AppData\Local\Temp\svcugzvu.tmp\svcuhb32.tmp. I then crashed AOO with TaskManager and svcuhb32.tmp remained. (NB - it is a copy of your file before any edits are made.).
I reopened crashtest.odt and it successfully recovered it as it was when I previously opened it - ie without my edits. This is expected.

I repeated the test and crashed AOO. I then renamed the temporary file C:\Users\John\AppData\Local\Temp\svcuttj7.tmp\svcuua9n.tmp" to svcuua9n.odt. I opened it and got the message that crashtest.odt was being recovered - it recovered successfully. I pressed NEXT and the file opened as before but I also got the same error message you got. This suggests an examination of what happens to that temporary file may be interesting.
Clipboard01.png
See [Tutorial] How to find and un-delete AOO temporary files for an explanation of temporary files.
Attachments
test.odt
(9.96 KiB) Downloaded 430 times
LO 6.4.4.2, Windows 10 Home 64 bit

See the Writer Guide, the Writer FAQ, the Writer Tutorials and Writer for students.

Remember: Always save your Writer files as .odt files. - see here for the many reasons why.
hman2
Posts: 63
Joined: Sun Nov 22, 2020 11:51 pm

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by hman2 »

John_Ha wrote: Excellent. You will therefore presumably agree it is a problem with your environment as other Mint users don't have problems with tables.
You didn't read my postings! Of course I do NOT agree.
John_Ha wrote: Diagnosis is therefore required to identify the factor causing your problem.
That's a tautology...

It is not "my problem", it is a problem in the ITIL (ISO 20.000) meaning of the word (source for a recurring incident). Programs must NEVER, EVER crash. They may, under some circumstances, abort prematurely. But NEVER without a (meaningful) error message. But this is a crash. If a program crashes, this is always enough evidence that it does contain a bug in the programming that needs a solution (not a workaround). It would only be "my problem" if I were a developer and scheduled to examine the root cause and prepare a solution, which I cannot do without deeper knowledge of the inner workings of the code.

And diagnosis is always required to find the root cause of a problem.
John_Ha wrote:Have you reset the user profile?
Again, you did not read my postings. I installed from scratch. But just for the sake of your argument, I did also rename ~/.openoffice for testing, which is equivalent to "resetting the profile". Doesn't change anything, still crashes.
John_Ha wrote:Incidentally, I tried to reconstruct your scenario by opening your file. This created a temporary file C:\Users\John\AppData\Local\Temp\svcugzvu.tmp\svcuhb32.tmp. I then crashed AOO with TaskManager and svcuhb32.tmp remained. (NB - it is a copy of your file before any edits are made.).
I reopened crashtest.odt and it successfully recovered it as it was when I previously opened it - ie without my edits. This is expected.
Why is this expected? On the contrary, this behaviour is contradictory to labelling it a "recovery". First, you had to do it manually. AOO claims to this by itself - but fails, despite claiming "success". This is another bug. Second, losing all edits is just pointless. You could simply open the original file to get the same effect. AOO does not damage that when it crashes. And if you did what is recommended to do "save early, save often", then the ORIGINAL file might event be the better starting point, because it contains at least some edits, while the other does not.
John_Ha wrote: I repeated the test and crashed AOO. I then renamed the temporary file C:\Users\John\AppData\Local\Temp\svcuttj7.tmp\svcuua9n.tmp" to svcuua9n.odt. I opened it and got the message that crashtest.odt was being recovered - it recovered successfully. I pressed NEXT and the file opened as before but I also got the same error message you got. This suggests an examination of what happens to that temporary file may be interesting.
To shed some light on that: Observing /tmp reveals that a crash does things vastly differently than killing the program (on Windows you probably don't even know which signal was sent to the program... If you send a SIGTERM then the program should close all open handles and exit gracefully, something that a crash doesn't. Use kill -9 instead). On a crash, the temp directory in /tmp with the random name stays intact, of course (because nothing could delete it). But you get the window "Open Office document recovery", which means that AOO has already kind of restarted. Once you click on the only button (Ok), the file within the random directory gets renamed and immediately after that deleted - along with the random directory, and a new random directory is created, which is empty. Of course recovery must fail after that...
OpenOffice 4.18 on Linux Mint 18
hman2
Posts: 63
Joined: Sun Nov 22, 2020 11:51 pm

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by hman2 »

If it would be a real word document and not this crashtest "stub", a user might have typed long texts. Being thrown back to the original is close to a disaster. A recovery must protect from that. Of course a recovery worth the name would reinstate all but the very latest edits (so all before the last occurrence of an automated save in the /tmp directory.

Therefore, I again opened crashtest.odt, entered a new line (in line 2) and let sit for the stretch of 8 minutes. That ought to be enough for at least one touch of the temp file. Then I provoked the crash, again. And before the recovery window deleted the temp file in the random directory in /tmp, I copied it, renamed it trial.odt. Then I ran though the "recovery" (which of course failed again). Closed AOO. Reopened AOO and opened trial2.odt.

And - nothing. My edit was lost, although AOO had 8 minutes of idle to do some saving, but it did not.

I will redo this test and have a command line window of /tmp open to see when the file gets touched.
OpenOffice 4.18 on Linux Mint 18
hman2
Posts: 63
Joined: Sun Nov 22, 2020 11:51 pm

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by hman2 »

Another observation:

The file in /tmp has an incorrect timestamp. It does carry the date/timestamp of the original file...

XXXX@YYYY /tmp/sv8fw0z9.tmp $ ls -al
insgesamt 32
drwxr-xr-x 2 XXXX XXXX 4096 Dez 28 11:49 .
drwxrwxrwt 22 root root 16384 Dez 28 11:49 ..
-rw-r--r-- 1 XXXX XXXX 9497 Dez 24 10:44 sv8fwenf.tmp
OpenOffice 4.18 on Linux Mint 18
hman2
Posts: 63
Joined: Sun Nov 22, 2020 11:51 pm

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by hman2 »

A quarter of an hour later, the temp file hasn't been touched even once:

XXXX@YYYY /tmp/sv8fw0z9.tmp $ ls -al
insgesamt 32
drwxr-xr-x 2 XXXX XXXX 4096 Dez 28 11:49 .
drwxrwxrwt 22 root root 16384 Dez 28 11:57 ..
-rw-r--r-- 1 XXXX XXXX 9497 Dez 24 10:44 sv8fwenf.tmp
OpenOffice 4.18 on Linux Mint 18
hman2
Posts: 63
Joined: Sun Nov 22, 2020 11:51 pm

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by hman2 »

Looks like AOO never writes anything there. After almost two hours, the file is still untouched...

But... in ~/.openoffice is a directory named ~/.openoffice/4/user/backup, containing a file crashtest.odt_0.odt -which voilà - DOES contain the edits...
OpenOffice 4.18 on Linux Mint 18
hman2
Posts: 63
Joined: Sun Nov 22, 2020 11:51 pm

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by hman2 »

The file ~/.openoffice/4/user/backup/crashtest.odt_0.odt is NOT created immediately upon edit. Instead, it gets created only one quarter of an hour later after the edit...
OpenOffice 4.18 on Linux Mint 18
John_Ha
Volunteer
Posts: 9583
Joined: Fri Sep 18, 2009 5:51 pm
Location: UK

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by John_Ha »

hman2 wrote:Looks like AOO never writes anything there. After almost two hours, the file is still untouched...

But... in ~/.openoffice is a directory named ~/.openoffice/4/user/backup, containing a file crashtest.odt_0.odt -which voilà - DOES contain the edits...
Both are as expected - see the Tutorial I referred you to.

I see you did not bother even to download the test file I uploaded so I will cease my contributions.
LO 6.4.4.2, Windows 10 Home 64 bit

See the Writer Guide, the Writer FAQ, the Writer Tutorials and Writer for students.

Remember: Always save your Writer files as .odt files. - see here for the many reasons why.
hman2
Posts: 63
Joined: Sun Nov 22, 2020 11:51 pm

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by hman2 »

I did read the "tutorial". But it doesn't help. First, it is only valid for Windows. Second, it does contain serveral errors. For instance:
When you have an SSD, the Operating System works silently in the background to set all the bits in deleted files to zero so, unfortunately, you may not find that many deleted temporary files!
That is just simply untrue. If an operating system would do that, it would drastically (!) increase wear and tear on an SSD. The guaranteed lifespan of an SSD is seldom more than 100,000 writes per cell. This text seemingly confuses zeroing either with the SATA command 'TRIM' which tells the SSD which blocks are currently un-used, so that the wear-levelling mechanism built into ALL SSDs can add unused filesystem space to the amount of reserve blocks that are always present, but inaccessible to the operating system. Or with the "object reuse protection":

https://docs.microsoft.com/en-us/sysint ... ds/sdelete
The only way to ensure that deleted files, as well as files that you encrypt with EFS, are safe from recovery is to use a secure delete application. Secure delete applications overwrite a deleted file's on-disk data using techiques that are shown to make disk data unrecoverable, even using recovery technology that can read patterns in magnetic media that reveal weakly deleted files. SDelete (Secure Delete) is such an application.
Windows automatically issues TRIM commands, Linux does this manually via the fstrim command. Neither Windows nor Linux zero deleted files.

The reason why on both Windows and Linux you will indeed not find many deleted files is that the blocks they occupied REPORT as zero once they are unallocated (and TRIMed). Actually the data is still there, but unobtainable, but it now resides in the bulk of reserved blocks for wear level management.

However, all of this is totally irrelevant if a program writes its temporal data from memory to hard disk ("save early, save often" can be automated). However, I do not complain loss of data. There hasn't been any. I did report a bug, and a crash is under all circumstances evidence of a bug.
OpenOffice 4.18 on Linux Mint 18
hman2
Posts: 63
Joined: Sun Nov 22, 2020 11:51 pm

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by hman2 »

the temporary folder is located at /home/xxxxxx/.openoffice/4/user/temp/ (Check Tools > Options > Paths).
Nope. That folder exists, but remains empty. Nothing gets stored there. However, some temporary files are written in /tmp, where a folder with a random name (starting with sv) gets created. For security reason that is very okay, but means that no static path can be given either in the tutorial nor in Options/Paths (which is actually Extras | Options | OpenOffice | Paths). These are created dynamically and destroyed, leaving nothing behind. However, the temp file in ~/.openoffice/4/user/backup contains everything needed in case of a crash.

Oh, and something I did not see before: The 15 minutes intervall is a default... So I see this only because I renamed, at your request, my .openoffice. I had a much more recommendable period of 1 minute, so disabling my profile put me back to 15 minutes... IMHO 1 min is a good compromise between wearing out an SSD to losing too much data upon a crash.
OpenOffice 4.18 on Linux Mint 18
User avatar
Hagar Delest
Moderator
Posts: 32628
Joined: Sun Oct 07, 2007 9:07 pm
Location: France

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by Hagar Delest »

hman2 wrote:Programs must NEVER, EVER crash. They may, under some circumstances, abort prematurely. But NEVER without a (meaningful) error message. But this is a crash. If a program crashes, this is always enough evidence that it does contain a bug in the programming that needs a solution
Everyone agree with the fact that programs should not crash. However, a crash is usually a situation where the program is lost. Therefore, it is not realistic to expect the program to investigate how it occurred. You may have a crash report for some applications but I've hardly seen any meaningful error message inside.
You can't disregard the fact that the code may be influenced by the environment too. If your issue is not reproducible with different environments, then there is something on your machine that is quite specific. Then, that's a different story to find the smoking gun. It's therefore a bit hasty to ask for a fix. It would be more interesting if another Mint user could evidence the same crash with your file.

To make it short for temporary files, here is another quick explanation (in Re: Data loss) that should shed some light:
John_Ha wrote:When you open Fred.odt, AOO takes a copy of Fred.odt and places it a temporary location as something like C:\Users\xxxxxx\AppData\Local\Temp\sv6a8vhe.tmp\sv6a8vt4.tmp. If AutoSave is switched on, this temporary file is updated each AutoSave; if AutoSave is not switched on, the temporary file remains as it was when the document was opened. The document data is loaded into memory and all edits and changes are retained in memory and are not written to disk while the file is open. The exception is adding graphics, where the graphics metadata is stored in memory, but the images themselves are written as temporary files to disk after the Remove from memory period has elapsed, or the allocated graphics memory has been exhausted.
 Edit: Correction from John_Ha:
1. The temp file \Temp\sv6a8vhe.tmp\sv6a8vt4.tmp is never changed
2. AutoSave creates a file in the \Backup folder called fred.odt_0.odt and this file is updated with each AutoSave. 
To prevent data loss anyway, frequent manual save is the only way.
You should try LibreOffice, it is more actively developed. If you've filed a bug report, can you post the link so that we can have a look?
Personally, I deactivate the autorecovery feature because it stalls the application with big documents.
LibreOffice 7.6.2.1 on Xubuntu 23.10 and 7.6.4.1 portable on Windows 10
hman2
Posts: 63
Joined: Sun Nov 22, 2020 11:51 pm

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by hman2 »

Hagar Delest wrote:However, a crash is usually a situation where the program is lost. Therefore, it is not realistic to expect the program to investigate how it occurred. You may have a crash report for some applications but I've hardly seen any meaningful error message inside.
I do not expect a program to investigate how a crash occured. Which is impossible simply by the fact that the crash occurred, so the program is no longer executed... This is why a meaningful error message is of the utmost importance. Was it a missing ressource, was it a division by zero, was it a segfault. Without this information it is almost impossible to find the root cause.

But if you look at the output of soffice on stdout/stderr, you see numerous (!) complaints by some library that ressource allocation is, to say the least, "not robust".

Upon start you get the warning "** (soffice:28205): WARNING **: Unknown type: GailWindow". And each and every time you click onto main menu's File, you get two complaints "(soffice:28205): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed (soffice:28205): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed".

Just start it from command line and watch the window for a couple of minutes...
Hagar Delest wrote:You can't disregard the fact that the code may be influenced by the environment too. If your issue is not reproducible with different environments, then there is something on your machine that is quite specific.
That assumption seems logical, but it is not. Only (!) if it can be "100,000% assured" that the others that try to reproduce a fault are really doing the very exact same thing. And this is a prime example of this. You said it did not crash for you. I have now found that is important WHERE you insert the newlines. If that is done on line 2 and NOT immediately before the table, then it doesn't crash for me, too... With that we have proof (!) that there is something special with this line directly above the table. It behaves different than line 2, although both are painted empty, showing only the paragraph sign.
Hagar Delest wrote:Then, that's a different story to find the smoking gun. It's therefore a bit hasty to ask for a fix. It would be more interesting if another Mint user could evidence the same crash with your file.
In my 30+ years after I left university I have only witnessed about a dozen or so instances, where any environment would be able to destabilize a robustly coded application, and all of them were on Windows, where Microsoft cannot even get a grip on their own update mechanism to run robustly across the world. On Linux it is very hard for one process to interfere with another even wilfully, even more so accidentally. Although technically possible, it rarely happens.

If you have trouble coming from the environment, then almost always you see it immediately upon start (or failure to start). If you have the wrong glibc, you'll see it immediately. But it won't happen, because you would get the error message upon installation, because dpkg will tell you! There is no "DLL hell" on Linux. With Java it can get complicated, but then Java will give you lots of opportunity to debug or to narrow down your root causes.
Hagar Delest wrote: If you've filed a bug report, can you post the link so that we can have a look?
I have to wait to get an account created...
OpenOffice 4.18 on Linux Mint 18
User avatar
Villeroy
Volunteer
Posts: 31269
Joined: Mon Oct 08, 2007 1:35 am
Location: Germany

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by Villeroy »

hman2 wrote:On Linux it is very hard for one process to interfere with another even wilfully, even more so accidentally. Although technically possible, it rarely happens.
OpenOffice is a patchwork monster. Compiling OpenOffice on any platform is very diffcult which is the reason why there is no version for 64-bit Windows. One of the very first things that had been done with the LibreOffice fork was cleaning up the code, reduce the zoo of supplementary tools in order to make the code more accessible to developers.
On my Ubuntu Linux, OpenOffice freezes when I open documents with database forms when I click on a table control. This particular problem goes away when I switch from X11 display server to the still experimental Wayland server. However, Wayland does not support floating toolbars yet. LibreOffice docks all toolbars when it is started under Wayland. OpenOffice crashes when I try to use drop-down buttons on floating toolbars. I have to start my desktop under Wayland and dock all toolbars before I can use a stable OpenOffice. Every 3rd or 4th document I open contains a table control. My most important component is Base, second is Calc in connection with Base and most of my Text documents have some kind of input form or another connection to the Base component.
 Edit: Something has changed in Wayland (certainly not in AOO). Floating toolbars do work by now. 
Please, edit this topic's initial post and add "[Solved]" to the subject line if your problem has been solved.
Ubuntu 18.04 with LibreOffice 6.0, latest OpenOffice and LibreOffice
Bill
Volunteer
Posts: 8932
Joined: Sat Nov 24, 2007 6:48 am

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by Bill »

For the first problem:
I can't reproduce the crash using AOO 4.1.8 on Linux Mint 20.

For the second problem:
hman2 wrote:Clicking on "Start recovery" produces the error message /tmp/sv201khp.tmp/crashtest.odt_0.odt would not exist. This is true, because the entire directory in /tmp has a different name (sv2o9ee3.tmp) and that only contains one file named 0.odt...
The file name "crashtest.odt_0.odt" appears correct for the autorecovery file, but the directory is wrong. The error message is telling me that the path setting for backups should be checked. In AOO, select Tools > Options > OpenOffice > Paths. Check the path for Backups. That's the path AOO uses to save and look for the autorecovery file. It should be to the "backup" folder in the user profile, not some folder in /tmp which has a random name.
AOO 4.1.14 on Ubuntu MATE 22.04
User avatar
robleyd
Moderator
Posts: 5056
Joined: Mon Aug 19, 2013 3:47 am
Location: Murbko, Australia

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by robleyd »

Here's a wild guess based on a comment in a bug report. Are you using Mint-y themes as default? If so, try switching control panels to Mint-x or related themes.
Cheers
David
OS - Slackware 15 64 bit
Apache OpenOffice 4.1.15
LibreOffice 24.2.1.2; SlackBuild for 24.2.1 by Eric Hameleers
hman2
Posts: 63
Joined: Sun Nov 22, 2020 11:51 pm

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by hman2 »

Another observation:

Out of curiosity (without deeper knowledge of the inner program structure, coding paradigms and library the following is just a shot in the dark, and I got lucky!) I ran AOO in gdb, GNU's debugger.

And voilá, I do get a meaningful error message. The actual fault is now visible, and it is severe: It's a segfault!

Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault.
0x00007fffe35e41ed in ?? ()
from /usr/lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0

The libatk (1,0-0) from my Mint 18 is version 2.18.0-1. Synaptic tells me that the last change of code in libatk was back in 2015, so that was before I switched to Mint Sylvia:

atk1.0 (2.18.0-1) unstable; urgency=medium
* New upstream release.
-- Michael Biebl <biebl@debian.org> Wed, 23 Sep 2015 19:51:09 +0200

atk1.0 (2.16.0-2) unstable; urgency=low
* Upload to unstable.
* Bump Standards-Version to 3.9.6 (no changes).
-- Mario Lang <mlang@debian.org> Tue, 05 May 2015 12:58:51 +0200

Now that this segfault is outside of AOO, and in a library, does not yet mean that AOO is not the culprit. To determine this, AOO should undergo a stacktrace to really see what gets fed into libatk so that it segfaults. Breakpoints would be handy. Many segfaults happen because of bad parameter passing... But the naming of the library gives me puzzles "x86_64-linux-gnu/libatk-bridge" really looks like (haven't googled it yet) a 32-to-64-bit crossbreed. Which then is something haunting Windows for long ("SysWoW32" - WoW is "Windows on Windows"...).
OpenOffice 4.18 on Linux Mint 18
hman2
Posts: 63
Joined: Sun Nov 22, 2020 11:51 pm

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by hman2 »

Bill wrote: The file name "crashtest.odt_0.odt" appears correct for the autorecovery file, but the directory is wrong. The error message is telling me that the path setting for backups should be checked. In AOO, select Tools > Options > OpenOffice > Paths. Check the path for Backups. That's the path AOO uses to save and look for the autorecovery file. It should be to the "backup" folder in the user profile, not some folder in /tmp which has a random name.
The path named "backup" does point to ~/.openoffice/4/user/backup. There is path named "temporary" which points to /tmp. And these are the defaults, as I have temporarily disabled my profile on the request of John_Ha.
OpenOffice 4.18 on Linux Mint 18
hman2
Posts: 63
Joined: Sun Nov 22, 2020 11:51 pm

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by hman2 »

Bill wrote:For the first problem:
I can't reproduce the crash using AOO 4.1.8 on Linux Mint 20.
Pardon the question, but did you enter those newlines to the blank line immediately above the table (NOT line 2) ? I ask, because adding on line 2 doesn't crash here, too. Only additions to the line directly above the table. This is a somehow special line where something is different.

Second, could you please indicate the version of libatk, as the crash (see my posting on gdb output) actually doesn't happen inside AOO, but in libatk, which for unknown reason segfaults when the last row of the table wraps over to the next page?
OpenOffice 4.18 on Linux Mint 18
hman2
Posts: 63
Joined: Sun Nov 22, 2020 11:51 pm

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by hman2 »

hman2 wrote:But the naming of the library gives me puzzles "x86_64-linux-gnu/libatk-bridge" really looks like (haven't googled it yet) a 32-to-64-bit crossbreed. Which then is something haunting Windows for long ("SysWoW32" - WoW is "Windows on Windows"...).
Googling ATK brings up a suprise: ATK is the "Accessibility Technology Toolkit", so the interface for readers for the blind, screen magnifiers, etc. I do not use any of those... So my set of ATK is just the Mint Sylvia default...

https://wiki.gnome.org/Accessibility/Do ... 2/AtkGuide

Peeking a little inside the lengthy documentation also reveals what the warning "** (soffice:17428): WARNING **: Unknown type: GailWindow" means, that AOO writes out to stdout/stderr EVERY TIME you start it. GAIL is a library in the Accessible GTK+ applications framework:
https://wiki.gnome.org/Accessibility/Do ... _Practices

Look at the block diagram. GAIL is responsible for "accessibility objects and interfaces". So the unknown type becomes clearer: This framework seemingly expects something like a "GailWindow" object to exist, but cannot find it. Wow. From here on, it's for the code junkies to dig so deep that they can find out whether or not AOO must supply such an object (possibly a simple stub could be sufficient, but I have no knowledge) or whether GTK fails to deal with a program that just ignores accessibility features.
ATK is an in-process accessibility API, written to by applications and implemented for GTK+ widgets by GAIL (GNOME Accessbility Implementation Library), which a GTK application dynamically loads at runtime if the value of the accessibility gconf key (/desktop/gnome/interface/accessibility) is "true."
OpenOffice 4.18 on Linux Mint 18
Bill
Volunteer
Posts: 8932
Joined: Sat Nov 24, 2007 6:48 am

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by Bill »

hman2 wrote:Actually, in /tmp, there IS (while OO is running) a directory RANDOMNAME (probably for security reasons) with files 0.odt, and sv1.swzk0.tmp, MYDOCNAME.odt_0.odt.
I have installed Mint 18.3 and based on testing using 18.3, 0.odt should only be there after a document has been successfully recovered but hasn't been closed. 0.odt appears to be a copy of the recovered document. MYDOCNAME.odt_0.odt should never be there. That is the file that is used for document recovery and should only be in the backup folder in the user profile. The svxxxxxx.tmp file is the only file that should be there, but it is not used for document recovery.

I've also gone through the crash test procedure multiple times on Mint 18.3 using every line above the table. and the procedure has not produced a crash when the table moves down to the next page or at any other time. There must be a third factor that hasn't been discovered yet.
AOO 4.1.14 on Ubuntu MATE 22.04
hman2
Posts: 63
Joined: Sun Nov 22, 2020 11:51 pm

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by hman2 »

Bill wrote:There must be a third factor that hasn't been discovered yet.
Thanks for testing. Based on the above quoted research, one factor might be 'accessibility'. AOO comes with some accessibility features turned on by default. I never changed those settings, and my currently disabled profile ensures that no changes from me are active. But it isn't clear whether AOO defines "accessibilty" in the way GAIL does. I never had screen readers or anything like that, so all my accessibility features on OS level are also at their defaults. But since GAIL is a framework, another thing might differentiate between two Linuxes that on the surface look alike: The window management framework, which today does vastly more than just window management, hence they are called desktop environments. I use the Cinnamon version of Mint, so this is Gnome 3 based here in a Gnome 2 style. And my Mint is the "regular" (or "original") Mint, i.e. based on Ubuntu.
OpenOffice 4.18 on Linux Mint 18
User avatar
robleyd
Moderator
Posts: 5056
Joined: Mon Aug 19, 2013 3:47 am
Location: Murbko, Australia

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by robleyd »

Did you try my suggestion above about themes?
Cheers
David
OS - Slackware 15 64 bit
Apache OpenOffice 4.1.15
LibreOffice 24.2.1.2; SlackBuild for 24.2.1 by Eric Hameleers
hman2
Posts: 63
Joined: Sun Nov 22, 2020 11:51 pm

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by hman2 »

I never used themes, so that is still on default (Mint-X). A check reveals that the desktop itself is not set to Mint-X, but to "Linux Mint". I've also never changed that.

Also, the bug report states that the user saw warnings about GAIL for years, so it has to assumed to be commonplace :-(
OpenOffice 4.18 on Linux Mint 18
Bidouille
Volunteer
Posts: 574
Joined: Mon Nov 19, 2007 10:58 am
Location: France

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by Bidouille »

Could you give us more details about UI used?
Gnome, Xfce, etc...
hman2
Posts: 63
Joined: Sun Nov 22, 2020 11:51 pm

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by hman2 »

Bidouille wrote:Could you give us more details about UI used?
Gnome, Xfce, etc...
As I wrote above, this is Linux Mint 18.3 in the Cinnamon edition, which is based on Gnome 3, but with a Gnome 2 look & feel (i.e. with a task bar).
OpenOffice 4.18 on Linux Mint 18
User avatar
Hagar Delest
Moderator
Posts: 32628
Joined: Sun Oct 07, 2007 9:07 pm
Location: France

Re: Frequent crashes of 4.1.8 on Linux, recovery non-functio

Post by Hagar Delest »

Any chance you try with LibreOffice? At least for test purpose, you're free to revert to AOO afterward.
LibreOffice 7.6.2.1 on Xubuntu 23.10 and 7.6.4.1 portable on Windows 10
Post Reply