Hi Jeff,
Looks like the expose event isn't propagated somehow to the widget.
Maybe the a11y code it consuming the expose event instead of
propagating it (e.g. returning FALSE
instead of TRUE in the callback chain).
Did you try to simply the problem by only trying to display this
specific dialog box ?
Erwann
Jeff Cai wrote:
> Jeremy Y Uejio wrote:
>
>> Is it possible that some other dialog window has popped up and is
>> waiting for input? That window might be hidden by other windows or
>> the main window.
>>
> From the stack trace, only one dialog popped up and there're no other
> windows waiting for input.
>
> Jeff
>
>> jeremy
>>
>> On 09/ 4/08 02:47 AM, Jeff Cai wrote:
>>
>>> Hi,
>>>
>>> Recently I am working on an Evolution bug
>>> http://bugs.opensolaris.org/view_bug.do?bug_id=6742853. This bug was
>>> also reported on GNOME bugzilla
>>> http://bugzilla.gnome.org/show_bug.cgi?id=550710. When you use
>>> Evolution first time and setup the local user first time, Evolution
>>> hangs. You can reproduce it after vermillion 92 with following steps:
>>>
>>> 1. Login in JDS.
>>> 2. Launch Evolution. (Note, a11y should be enabled)
>>> 3. Set up the local mail account.
>>>
>>> After you click the "Apply" button to complete this setup, Evolution
>>> hangs. The next window becomes blank and doesn't response to any
>>> mouse or keyboard messages.
>>> This is the stack trace:
>>>
>>> $ pstack 6563
>>> 6563: evolution
>>> feefdce7 pollsys (8435380
>>> <http://monaco.sfbay/detail.jsf?cr=8435380>, e, 8046c08, 0)
>>> feeaf3f2 poll (8435380
>>> <http://monaco.sfbay/detail.jsf?cr=8435380>, e, 18f) + 52
>>> fec8005b g_main_context_iterate (80a9e40, 1, 1, 807eb80) + 397
>>> fec80694 g_main_loop_run (85f0de0) + 1b8
>>> fe4fb2c9 gtk_dialog_run (8149820
>>> <http://monaco.sfbay/detail.jsf?cr=8149820>) + 171
>>> f8bc238c em_utils_prompt_user (0, f3a00f50, f3a00efc, 0) + b0
>>> f3a00e5e org_gnome_default_mailer_check_default (80a2698, 83aad10) +
>>> 15a
>>> f9d023c1 epl_invoke (80a2698, 811b938, 83aad10) + 65
>>> f9d01e65 e_plugin_invoke (80a2698, 811b938, 83aad10) + 51
>>> f9cfc9bf emph_event_handle (80bf880, 810a120, 810a480) + 33
>>> f9cfc8c8 e_event_emit (80bf880, 8065df4, 83aad10) + f0
>>> 0805d5b5 e_shell_attempt_upgrade (80e63b0) + 431
>>> 0805cebd e_shell_construct (80e63b0, 8065f20, 0) + a5
>>> 0805cfe7 e_shell_new (0, 8047044
>>> <http://monaco.sfbay/detail.jsf?cr=8047044>) + 27
>>> 08064889 <http://monaco.sfbay/detail.jsf?cr=8064889> idle_cb (0) + 169
>>> 0806465d show_development_warning (80471e4, 80470c8, feffb7dc, 0, 0,
>>> 0) + 321
>>> 08064ee7 main (1, 804710c, 8047114
>>> <http://monaco.sfbay/detail.jsf?cr=8047114>) + 3d3
>>> 0805b4b2 _start (1, 804724c, 0, 8047256
>>> <http://monaco.sfbay/detail.jsf?cr=8047256>, 8047290
>>> <http://monaco.sfbay/detail.jsf?cr=8047290>, 80472a9) + 7a
>>>
>>>
>>> My investigation results:
>>>
>>> 1. no dead lock since the stack trace indicates that it is not
>>> hanging in waiting for a certain resource. Meanwhile, I can use
>>> accerciser to click the button.
>>> 2. Although this bug doesn't happen when a11y is disabled, we can not
>>> find the evidence that this bug lies in a11y code.
>>> 3. With dtrace, we saw that gtk_window_expose is not called when the
>>> window becomes blank.
>>> 4. If we start evolution with --sync option (Make X calls
>>> synchronous), this bug goes away.
>>> 5. We found that the calling sequence of "g_main_loop_run" and
>>> "g_main_loop_exit" is normal.
>>>
>>> Here, I ask for some pointers:
>>> How to debug the issue like the window is not painted?
>>>
>>> Thanks
>>>
>>> Jeff
>>>
>>> _______________________________________________
>>> desktop-discuss mailing list
>>> desktop-discuss at opensolaris.org
>>>
>
> _______________________________________________
> desktop-discuss mailing list
> desktop-discuss at opensolaris.org
>
--
Erwann Ch?ned?,
Desktop Group, Sun Microsystems, Grenoble
Phone : +33 476 188 358 ext: 38358
