Issue 56302 - deadlock after opening non-existent document while modal dialog is present
Summary: deadlock after opening non-existent document while modal dialog is present
Status: CONFIRMED
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOO 2.0 Beta2
Hardware: PC Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-20 08:42 UTC by sonicsummer
Modified: 2017-05-20 11:29 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
relevent bits of stacktrace (9.52 KB, text/plain)
2006-02-13 10:54 UTC, caolanm 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description sonicsummer 2005-10-20 08:42:56 UTC 
Here is how to reproduce the bug.

1. start openoffice from shell in background:

/opt/openoffice.org2.0/program/soffice &

2. Wait until the 'OOo-writer' window appears and select menu item 'File -
Open'.  This opens a modal dialog.  Leave this dialog open.

3. Go back to the shell and start openoffice with a non-existent file:

/opt/openoffice.org2.0/program/soffice some-non-exiting-file

4. Now we have another dialog telling that the file could not be found. Try
closing either of the dialogs.  On my system neither dialog reacts on mouse
clicks (to be precise: the fial dialog still reacts on button clicks and allows
browing around in the file system; but any clicks on the Ok or Cancel buttons
are ignored).

This looks like a classic event-loop in the event-loop problem.

IMHO the second invocation of openoffice should be blocked until the running
openoffice program is in its idle loop (back in the main event loop).
Comment 1 thorsten.martens 2005-10-24 09:19:07 UTC 
Partly reproducible on Suse Linux 9.3. As long as the second dialog is shown,
the file-picker doesn´t work. But the second dialog (the errormessage) can be
closed and then, the file-picker works again.
TM->HRO: please have a look, thanks !
Comment 2 sonicsummer 2005-10-25 03:01:29 UTC 
Thanks for looking into this.  Note that I am using the system dialogs (gtk). 
If I select preferences item 'Use openoffice.org dialogs' then I get the
behavior you describe (2nd dialog can be closed).  With the system dialogs, the
2nd dialog does not respond and the only way to quit openoffice is by a kill -9
pid.  I think the problem is more general; any modal dialog that runs in its own
event loop could probably cause this problem.
Comment 3 hennes.rohling 2006-02-07 15:11:05 UTC 
Guess this is rather P4. hro->pl: Can't please have a look on this ?
Comment 4 philipp.lohmann 2006-02-07 15:30:10 UTC 
This seems to be an interaction between vcl modal dialogues and the gtk
filepicker; could you please have a look ? Perhaps we need to arrange something
regarding modality.
Comment 5 caolanm 2006-02-09 12:53:43 UTC 
cmc->mmeeks: any bright ideas before I go into the hell that this is likely to
lurk here.
Comment 6 mmeeks 2006-02-13 10:21:34 UTC 
Well - I'd like to see a stack trace to rule out multi-threaded evilness 1st :-)
- though I guess that that's not an issue - since we actually see the warning
dialog itself.

I would imagine that it's a case of gtk+'s idea of handling modality fighting
VCL's idea of how to handle modality ;-)
Comment 7 caolanm 2006-02-13 10:54:37 UTC 
Created attachment 34110 [details]
relevent bits of stacktrace
Comment 8 caolanm 2006-02-13 10:55:34 UTC 
reassigning
Comment 9 Marcus 2017-05-20 11:29:47 UTC 
Reset assigne to the default "issues@openoffice.apache.org".