Bug 88092 - Globals are not available as expected
Summary: Globals are not available as expected
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
(earliest affected)
3.5.4 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
Depends on: 88448 88442
  Show dependency treegraph
Reported: 2015-01-06 05:14 UTC by Bill Gradwohl
Modified: 2021-12-03 04:33 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:

testingA version (12.30 KB, application/vnd.oasis.opendocument.base)
2015-01-06 05:14 UTC, Bill Gradwohl
testingB version (12.23 KB, application/vnd.oasis.opendocument.database)
2015-01-06 05:15 UTC, Bill Gradwohl
Lionel's testing version (13.34 KB, application/vnd.sun.xml.base)
2015-01-15 06:46 UTC, Lionel Elie Mamane

Note You need to log in before you can comment on or make changes to this bug.
Description Bill Gradwohl 2015-01-06 05:14:19 UTC
Created attachment 111825 [details]
testingA version

My testing was done on Fedora 20 with LibreOffice downloaded from Libreoffice, and on Fedora 21 with LibreOffice as supplied by Fedora.

The attached files are identical except that testingA has Sub Main executed at Document open, and testingB has Sub Main executed at Form/Document open.

The database associated with each file is empty, so the event PriorToReset will execute the Sub PriorToReset immediately when the form is opened.

Please run testingA and note its behavior and then run testingB and note the drastic differences.

testingA will display a msgbox output from Main immediately upon execution. It proves that the struct and the string are properly initialized in Main.
testingB never displays that msgbox, so the conclusion must be that Main never ran. That's to be expected since the Sub Main is supposed to run at form/Document open time.

For testingA, executing the form shows the first of several msgbox outputs that can only mean the struct has lost its initialization, but the string maintains the initialization. Subsequent msgbox outputs are identical to the first. Note the final value that appears in the Date field. It is the default date I set as the minimum date.

For TestingB, executing the form again shows the first of several msgbox outputs, the first of which shows that neither the struct or the string are initialized. The second and subsequent msgbox outputs show that both the struct and string are now somehow miraculously initialized properly. Note the date in the date field. That's what it should contain. Further note that the msgbox from the Sub Main is never displayed during the entire testingB execution. That msgbox should have been the first msgbox to display at form startup, but it never showed.

Can you rationally explain the differences in these executions as not being a bug?

Essentially both LibreOffice environments I have access to produced the same results.

The operational differences I saw between LibreOffice versions was that with Version, the msgbox outputs appear on the application screen and not on the form data entry screen. In version, all the msgbox outputs are on the form data entry screen where I would expect them.
Comment 1 Bill Gradwohl 2015-01-06 05:15:53 UTC
Created attachment 111826 [details]
testingB version

Second file attached
Comment 2 Robert Großkopf 2015-01-06 07:27:48 UTC
Have only downloaded testingB version.
If you open the form for editing the msgbox appears. This is the event "Open Document".
If you open the form for putting content into fields it isn't executed in this way. So I tried it with "View created". This event was executed for a form, which is opened for editing and opened for input data into fields.

Other documents outside a database couldn't be opend in the same different way (writeable and not writable). So I couldn't test the difference, for example, with a writer-document.
Comment 3 Bill Gradwohl 2015-01-06 13:16:35 UTC
I copied the two files from one machine to another and they both ran as I described them without any manipulations on my part. I have no idea why they won't run for you. I assume you're on a Linux box similar to mine. The only configuration change I made was to LibreOffice security by placing the directory holding the files into the trusted list for medium security to avoid having to see the enable/disable macro screen.
Please don't confuse the issue by bringing Writer into this. It may be peculiar to Base.
Look at the code. It's just a few lines and dramatically demonstrates that Base has a severe problem depending on how it's configured, and in no case is it doing what I would expect. The reason I spent a day developing this test case was because I was having issues with a real database I was developing. GLobals are being initialized and then their contents are being lost along the way, and being lost in different fashions depending on when Main is executed to do the initialization - either at Base application start up, or at form open. That's the reason for the two file versions as that's the difference between them. The code is so simple, anyone that manages to get it to execute would see what I'm referring to.
Comment 4 Robert Großkopf 2015-01-06 17:15:07 UTC
I have only described how it would give the same result and testingB would be able to give the right date you wish by execution Sub Main befor opening a form for editing.
Seems we misunderstand each other too much. I will remove my self from CC.
Comment 5 Bill Gradwohl 2015-01-06 17:48:36 UTC
BTW - running the macro attached to the open document event when one is just editing the form doesn't make any sense. Editing the form is a programmers job during development and running any macro as part of that exercise has no value.

The event should only trigger when the form is opened for use, not for edit.

It appears I've offended you in some way. I meant no disrespect or injury. I'm simply stating facts as I see them in the hope that it leads someone to investigate some serious issues with globals and how they get initialized via an event that runs Main.
Comment 6 Robinson Tryon (qubit) 2015-01-14 22:52:33 UTC
Lionel: Thoughts on this bug?
Comment 7 Lionel Elie Mamane 2015-01-15 06:25:01 UTC
I reproduce these behaviours with LibreOffice; I expect this is actually "inherited from OOo".

We are dealing with several different (but interacting) issues here:

1) You (Bill) expect the Sub's execution to be strictly serialised
   (that is, the one waits for the other to be completely finished before
   starting) but that is not the case; their execution can be interleaved.

2) MessageBox seems not to react well to being run concurrently
   (that is from two macros that run in parallel). The MessageBox
   calls of one of the two macros are just silently skipped.

3) There is indeed a problem with structs "losing" their value
   when the sub exits. That is, they act as local variables!

Point 1 means that there is a race condition between your initialisation in main and using the value in PriorToReset. Also, since a MessageBox call introduces a delay in the execution, the absence or presence of MessageBox calls modifies the interdependent behaviour, as does any reordering of statements or a busy delaying loop like "for i = 0 to 100000 / next i". Welcome to concurrent programming...

Point 2 means that even though you think Main is not run, it actually is. Only its MsgBox calls are "skipped over". You will find that if add a MsgBox right at the beginning of Main, that MsgBox will run, and it is the MsgBox calls of PriorToReset that will be skipped, while the other statements of PriorToReset execute correctly. The same if you put a "wait 500" at the beginning of PriorToRest. So actually in your "testingB", the first MsgBox of PriorToReset allows (by the time you take to click it away) time for "Main" to continue executing and initialise your globals, so by the time of the second MsgBox call, they are indeed initialised.

Noel, Uray, does Basic (or some hidden corner of our API...) offer any synchronisation / mutex / ... so that a Sub can wait for another Sub . I kinda expected the basic interpreter to be single-threaded, so I was kind of surprised that introducing a "busy wait loop" like:
   for i=0 to 100000
   next i
would make a difference, but I get a very clear result that introducing this loop in sub Main allows execution of sub PriorToReset to start before Main is finished (which seems to suggest that execution can be preempted and is not purely cooperative multitasking, where instructions like MsgBox and Wait would invoke Yield). OTOH, a busy wait in PriorToReset for a global that is set in main (after the loop) to change value leads to an infinite loop.

Oh... I think I get it... It can be preempted by the start of a new macro from an event (some code in LibreOffice calls the Basic interpreter), but is never preempted on the initiative of the Basic interpreter. Is that it?
Comment 8 Lionel Elie Mamane 2015-01-15 06:46:15 UTC
Created attachment 112268 [details]
Lionel's testing version

Here is Bill's document modified by me, where you can see all the things I tried to understand the concurrency execution behaviour, as commented out text.

It also contains a debugging logging to the "Form1" document itself which doesn't have the concurrency issues of MsgBox, and thus more clearly shows what is being run what.
Comment 9 Lionel Elie Mamane 2015-01-15 07:02:33 UTC
Argh, just noticed that my "Lionel's testing version" has main running on event "view created" instead of "open document", which changes things around a bit since the event order is:

 view created
 before reset
 open document
Comment 10 QA Administrators 2016-02-21 08:38:02 UTC Comment hidden (obsolete)
Comment 11 QA Administrators 2017-03-06 16:07:32 UTC Comment hidden (obsolete)
Comment 12 QA Administrators 2019-12-03 14:29:06 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2021-12-03 04:33:46 UTC
Dear Bill Gradwohl,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team