LibreOffice Crashes

[ArDrakho]

Before I log a support ticket. Is anyone experiencing LibreOffice crashing when you try re-open a previously saved document (i.e. odt, ods, docx, xlsx, …)?

I can create a new document and save it; then quit LibreOffice.
However, if I return later and try to re-open it, it immediately crashes and displays a “crash” window.

however, if I try to re-open the same document again…

Anyone else experiencing this?

Any thoughts? If others are experiencing this, I will open a support ticket.

Thanks ahead of time…

[MrEntropy]

Yep. Happens here, too.

[Zenja]

Same here. Booting into 6 week older revision of Haiku (March) and LibreOffice works great. Looking at the difference in packages, LibreOffice itself hasnt been updated, so its another package causing the problem.

[Begasus]

Looking at the issue and the missing symbol you posted on haikuports it looks like the same issue as with digikam.

digiKam & showFoto crashes on startup

Looks like the change came from the recent version bump for libxml2 which removed some functions regarding FTP, a rebuild for libxml2 with it enabled resolves the missing symbol, not the crash though. EDIT exiv2 has been fixed, had to fix the cmake config files in order to get digikam to find it and start the build, build for digikam is running atm on buildmasters, once done you should be able to update it to the latest revision, probably doesn’t fix the crash, but should fix the missing symbol…

[ArDrakho]

UPDATE: After additional checks, it seems to affect the documents of newer file types. The .doc, .sxw, .xls, and .rtf files open correctly with LibreOffice. Hmmm…I’m guessing here that libxml2 is not required to open the older file types. I will create a support ticket for this related issue.

[Null]

@Begasus

Looking at the issue and the missing symbol you posted on haikuports it looks like the same issue as with digikam.

Are there any plans to eliminate the breakage caused by erroneous packages?

[Begasus]

@Null

Are there any plans to eliminate the breakage caused by erroneous packages?

It’s not even sure atm this “is” related, but when I saw the missing symbol I thought about the removed functions in libxml2, mostly we take care of packages requiring libraries, in cases SONAME changes are involved, in this case the SONAME wasn’t an isssue, just that libxml2 removed the “FTP” functions without proper advertising causing the breakage. I’ve revbumped LO and build is running on the buildmaster (should take a while) which atleast should resolve the missing symbol (not sure if it fixes the crash).

Also we need to see that for merging library packages the SONAME is correctly filled in in the recipe (which was the problem for libsndfile before).

[Null]

What is needed at a minimum is some testing, either automated or manual, preferable both, in order to ensure that updated packages do not break anything.

[Begasus]

I don’t think there is some form of automatic testing here, mostly I check it manually here. I guess the easiest fix for this was to build libxml2 with --with-ftp to restore the missing funtions, but as that wasn’t done, the SONAME didn’t break dependency (so it doesn’t pick up the missing symbol until you launch the app).
Checked on 64bit and also get the crash, but I didn’t see the missing symbol there, so maybe it’s not related to libxml2 even.

EDIT Just checked 32bit which still seems to be fine.

[Null]

Manual testing would have caught the error, and so would automated.

By manual testing I am referring to a testing release (nightly → testing → stable) so users that use the testing release have an amount of time to spot and report errors.

By automated I am referring to tools that can spot missing symbols (and other errors).

One thought I’ve had is to automatically detect which symbols (if that is the correct term) each package requires and produces and any information about its api/abi version. If that is possible, packages could state which symbols they need instead of which package. Reservation for me using the wrong terminology since I don’t know them. What I mean is that packages should define what functions they need, not which packages. By knowing the functions the needed packages can be selected. Is this possible?

[Begasus]

Way out of my skills Maybe @korli can answer this one?

[PulkoMandy]

Listing all symbols in the package metadata would add several megabytes of data to the files overall, when the info is already available in the files packaged inside, it doesn’t seem that great a solution.

We are already doing dependencies at the executable or library level rather than at the package level, whiuch, indeed, doesn’t help at all in this case.

One possible improvement would be to run abi-compliance-checker on each update to see when functions are removed from a library and then we can make sure to test some of the dependant packages before shipping the change.

And, yes, we really need to not have a single branch at haikuports and have some kind of stable repository. Even if no one will use it because all apps in it will be out of date

[korli]

libxml2 can give some headaches:

2.10 changes ABI without warning (#433) · Issues · GNOME / libxml2 · GitLab

2.11.0: new libxml2 breaks ABI (#526) · Issues · GNOME / libxml2 · GitLab

[Begasus]

I’ve read those and found out through readelf that indeed the functions are missing, did a local rebuild for libxml2 with --with-ftp and the functions get restored then, but as upstream mentions (iirc) they were of no use.

[Munchausen]

@PulkoMandy

And, yes, we really need to not have a single branch at haikuports and have some kind of stable repository. Even if no one will use it because all apps in it will be out of date

That is what I was going to suggest. That is how e.g. Debian does it. Package changes are filtered through unstable, then into testing, then release.

[khallebal]

@Begasus

but as upstream mentions (iirc) they were of no use.

Why re-enable them then? do we need them for something? it seems to me the better approach is just to rebuild the packages that depend on libxml2 ?, this is just a suggestion though not a complaint, after all you’re the one doing all the work.

[korli]

@khallebal

Why re-enable them then? do we need them for something? it seems to me the better approach is just to rebuild the packages that depend on libxml2 ?, this is just a suggestion though not a complaint, after all you’re the one doing all the work.

Actually nothing was reenabled. The impacted packages get rebuilt or upgraded.

[khallebal]

Ah yes, sorry i misread his comment, i missed the the “local” part of it.

[Null]

Has there been any discussions and/or any decisions taken on future improvements regarding testing and improved tools to minimise breakage? Even if nobody has the time to work on it now, it would be good to have a plan documented and tickets created.

[nephele]

Making a plan to improve it really is the major part of the work required in this case : )