GNOME Bugzilla – Bug 336168
Core dumps when using LDTP and Firefox.
Last modified: 2007-01-13 02:59:26 UTC
Steps to reproduce: 1. Download the latest firefox nightly trunk build for solaris from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/contrib/latest-trunk/ . The build I downloaded was firefox-1.6a1.en-US.solaris2.10-sparc.tar.bz2. Extract the firefox binary files. 2. Enable the desktop accessibility support, then invoke this firefox. 3. Launch python and import LDTP package. 4. Execute the LDTP command 'guiexist' to try to capture the firefox. Expected result: LDTP could capture the firefox frame and return 1. Actual result: LDTP hangs. And if you Ctrl+C and Ctrl+D to terminate it, it dumps core. I posted stack trace below. Stack trace: -bash-3.00$ pstack core core 'core' of 3973: ----------------- lwp# 1 / thread# 1 -------------------- d2f68d25 __pollsys (80fa000, 2, 0, 0) + 15 d2f2b292 poll (80fa000, 2, ffffffff) + 52 d2d3aa61 g_main_context_iterate (80a4540, 1, 1, 80a0950) + 399 d2d3b09e g_main_loop_run (80aa568) + 1ba d291f3b2 bonobo_main (d2ba00e0, d2d00960, 80473c8, d2b8c098, d2ffb840, 80473ec) + 5e d2b8ea30 cspi_main (d2ffb840, 80473ec, d2ffd8f0, 80473ec, 8061ae8, 7fffffff) + 18 d2b8c098 SPI_event_main (7fffffff, 7fffffff, 2, 0, 0, 0) + 18 08061ae8 main (0, 8047414, 8047418) + 108 08060eda _start (0, 0, 8047548, 8047569, 804758a, 80476c7) + 7a ----------------- lwp# 2 / thread# 2 -------------------- d2f68d25 __pollsys (d2cb9fc4, 1, 0, 0) + 15 d2f2b292 poll (d2cb9fc4, 1, ffffffff) + 52 080618b2 ldtp_server_thread (0) + 62 d2f67a28 _thr_setup (d2ce2400) + 51 d2f67c80 _lwp_start (d2ce2400, 0, 0, 0, 0, 0) ----------------- lwp# 3 / thread# 3 -------------------- d2f04b90 strlen (8087fdc, d27edd6c, d27edc80, 0) + 30 d2f42735 vsnprintf (d27edcd0, 1, 8087fbc, d27edd6c) + 70 d2d41e10 g_printf_string_upper_bound (8087fbc, d27edd6c) + 28 d2d5f447 g_vasprintf (d27edd30, 8087fbc, d27edd6c) + 2f d2d4f93b g_strdup_vprintf (8087fbc, d27edd6c) + 2b d2d41b4d g_print (8087fbc, 8102528, 81033f9, 0) + 2d 08067f4d get_child_window_handle (8103318, 8102528) + dd 08068172 get_window_handle (0, 8102528) + e2 08068298 update_cur_window_appmap_handle (80fb238, d27edfa0) + 88 080685cc ldtp_gui_get_gui_handle (80fb238, d27edfa0) + ec 0806957a ldtp_gui_gui_exist (80fb238, d27edfa0) + 1a 08064665 handle_request (80fb238, 80ab0b8, d27edfa0) + 555 08065b28 handle_client (80ab058) + 338 d2f67a28 _thr_setup (d26d0000) + 51 d2f67c80 _lwp_start (d26d0000, 0, 0, 0, 0, 0) ----------------- lwp# 4 / thread# 4 -------------------- d2f68d25 __pollsys (80a8478, 9, 0, 0) + 15 d2f2b292 poll (80a8478, 9, ffffffff) + 52 d2d3aa61 g_main_context_iterate (8101120, 1, 1, 80f8630) + 399 d2d3b09e g_main_loop_run (8100510) + 1ba d2ac773a link_io_thread_fn (0) + 1e d2d54267 g_thread_create_proxy (80f8630) + 11b d2f67a28 _thr_setup (d26d0400) + 51 d2f67c80 _lwp_start (d26d0400, 0, 0, 0, 0, 0) Other information: For this firefox build, at-poke could capture the firefox main frame and failed to capture others, e.g. menu item, while GOK succeeded in doing so. This bug can be seen on vermilion_07/snv_35 with firefox build : Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9a1) Gecko/20060326 Firefox/1.6a1 .
Tim: Stack trace of this bug looks similar to bug #336139. Hope the patch attached in that bug should fix this bug too. Once the build is ready with that patch, maybe you can try regressing both the bugs and update the bug info. Thanks
Hopefully! I'll update these two bugs when the new build is ready. Thanks!
Is this still an issue with 0.7.0 or CVS?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!