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
