Apache OpenOffice Community Forum

With LO 6.1.5.2 in W10, macros experience no immediate problem when accessing GlobalScope.BasicLibraries. Properties are correct and methods work without incident. However, when LO closes, it reports "crash" and on reopening does crash recovery. This only happens when GlobalScope.BasicLibraries (or just BasicLibraries) is accessed. The access can be as limited as simply mentioning the name, for example:
sub test
GlobalScope.BasicLibraries
end sub
My macro libraries exercise a lot of functions but nothing else has this effect and it does not occur with LO 6.0.7.3 in Ubuntu-Mate 18.04. Any suggestions?

DavidHMcCracken wrote:With LO 6.1.5.2 in W10

6.1 release has been reached End of Life May 29, 2019
https://wiki.documentfoundation.org/ReleasePlan/6.1

DavidHMcCracken wrote:My macro libraries exercise a lot of functions but nothing else has this effect and it does not occur with LO 6.0.7.3 in Ubuntu-Mate 18.04. Any suggestions?

Save your work, shutdown the office, rename the profile folder and start again with a new user profile.

Thank you Bidouille for your response. To share my work with a wide range of users without forcing them to stay in lockstep I update only when I encounter a serious problem that requires updating. I don't think this is one of those because the problem doesn't occur in the older (albeit Linux rather than W10) version.

Thank you Villeroy but I don't see a user.backup file (or directory) under ~/.config/libreoffice/4/user in my Linux system or under C:\Users\me\AppData\Roaming\LibreOffice\4\user in the W10 system. In both systems there is a directory called backup but it is empty.

Your signature indicates that you are using Linux Mate where this procedure might work: Under Windows renaming the profile might look like: Be sure that the office (and any "quick starter") is closed.

I have found the root of this problem. The method to find the problem may be the most useful information here. Following Villeroy's suggestion, I started a fresh user profile and the problem was gone, as were all of my customizations but not my libraries. By testing a mix of the fresh and old files (what Villeroy wisely suggested saving as user.backup) I was able to quickly discover that the linchpin was registrymodifications.xcu. Similarly using a mix of fresh and old items in this, I discovered that the single controlling element was the global macro assignment to the Open Doc event. This was quite unexpected and I might not have ever found it by other methods. With this information, the problem could easily be tracked down using ordinary debugging procedures.

At the first Open Doc event, my library registers a termination listener (this is invoked when LO completely closes-- I use it to save persistent data changes). Subsequently accessing GlobalScope.BasicLibraries does something to cause termination to malfunction. Even with my termination listener reduced to doing nothing, the crash occurs. I found this behavior in LO 6.0.7.3, 6.1.5.2, and 7.0.5 but only in Windows. Not surprisingly, the error is revealed to be in a DLL, mergelo.dll (Linux doesn't use DLLs). This is a bug in LO but I discovered a simple workaround. Accessing BasicLibraries instead of GlobalScope.BasicLibraries avoids the problem. However, if BasicLibraries is accessed by a different library from the one that registers the termination listener, the problem does occur. Consequently, this remains a serious bug. It means that unrelated libraries that individually have no problems can inadvertantly collaborate to produce a crash.

For anyone who might want to investigate this further, the problem can be reproduced by executing the following code (which I put in Standard.Module1 for convenience).