Re: UITest_writerperfect_epubexport hang (only sometimes)

Hey,

On Tue, Jan 23, 2018 at 9:18 AM, Miklos Vajna <vmiklos@collabora.co.uk>
wrote:

> Hi Markus,
>
> I've added UITest_writerperfect_epubexport a while ago, and while I did
> not see it hanging in the recent past, both Noel and Stephan run into
> a hang of it from time to time.
>
> The code is here:
>
> writerperfect/qa/uitest/epubexport/epubexport.py
>
> The backtrace always looks like this:
> self.ui_test.execute_blocking_action() gets an UNO method where invoking
> it opens a dialog and the python method also gets a callback. When the
> hang happens, then it seems the problem is that the Python thread waits
> for the dialog to be closed, but in fact it's already closed, so it
> waits forever joining the python thread.

That is not really correct. The dialog is not closed which is actually the
problem. However I have now spend a few days looking at the code and
related code pieces and I have still no idea how this could happen.
If my understanding is not completely wrong there is no race condition in
the UI testing framework. I traced all the calls and could not find a case
where you can click on the ok button and the dialog will not be destroyed
unless the SvpSalInstance::DoReleaseYield never returns. Currently that
would be my best guess.



> I don't think there is anything really special in this test, rather I
> guess the problem happens here more frequently (than elsewhere) because
> normally these dialogs are invoked via UNO commands, where we just
> execute the UNO command, wait for the dialog to appear then work with
> it. (I did not look at the implementation, perhaps in this case there is
> no Python thread involved?)

> So I wonder -- do you think it would be possible or would make sense to
> have a way similar to self.xUITest.executeCommand (execute a blocking
> command async), but for UNO methods that open a dialog? I.e. also
> similar to self.ui_test.execute_blocking_action, but without an actual
> callback.

Well, the execute_blocking_action method already does that. It will execute
your call in a separate thread and waits with the execution of the handler
code until the event for the dialog has been received. That approach allows
to execute either normal blocking UNO commands or blocking UI actions. I
also spend quite some time now looking for potential race conditions and
could not find one as there is nothing being executed until the dialog
executed event has been received at which point access to the dialog will
work.

If someone can reproduce this case it would be nice to check a few things
in gdb.

The first one would be whether we actually are stuck in
SvpSalInstance::DoReleaseYield or are looping in Dialog::Execute?
The other one would be the value of pSVData->maWinData.mpExecuteDialogs
And the last thing would be whether the dialog is already disposed.


For now I pushed a patch that will let the tests fail instead of being
stuck.

Regards,
Markus

> Perhaps that would be a fix for these strange hangs.
>
> Backtraces:
> - python: https://pastebin.ca/3942603
> - native one: https://pastebin.ca/3942628
>
> (From a run that resulted in a hang for Noel.)
>
> Thanks,
>
> Miklos