Closed
Bug 269847
Opened 20 years ago
Closed 20 years ago
[gtk2] Itermittent crashes [@event_processor_callback() ]
Categories
(Core Graveyard :: GFX: Gtk, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 269585
People
(Reporter: mozilla_bugs, Assigned: blizzard)
Details
(Keywords: crash)
Crash Data
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20041112 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20041112 Ever since updating my one month old mozilla GTK2 trunk build to newest trunk, I'm experiencing intermittent crashes. I installed talkback.xpi, changed build id in master.ini to match my GTK2 build from Nov 12, and captured one crash: tb1950323M Rebuilt the tree with "-g", and captured (rather short) backtrace: [Switching to thread 1 (Thread 1024 (LWP 13715))]#0 0x40ee9ed2 in event_processor_callback (source=0xa75dbd8, condition=G_IO_IN, data=0xa2012d0) at nsAppShell.cpp:67 67 eventQueue->ProcessPendingEvents(); (gdb) bt #0 0x40ee9ed2 in event_processor_callback (source=0xa75dbd8, condition=G_IO_IN, data=0xa2012d0) at nsAppShell.cpp:67 #1 0x405993cc in g_io_unix_dispatch () from /usr/lib/libglib-2.0.so.0 #2 0x40576cdc in g_main_dispatch () from /usr/lib/libglib-2.0.so.0 #3 0x40577bc7 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #4 0x40577fb5 in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0 #5 0x405785ee in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #6 0x402a6185 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #7 0x40eea306 in nsAppShell::Run() (this=0x81179c8) at nsAppShell.cpp:142 #8 0x40e4cda4 in nsAppStartup::Run() (this=0x7008c) at nsCOMPtr.h:711 #9 0x0804cf21 in _init () #10 0x0804da0f in _init () #11 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6 $10 = {ref_count = 1, funcs = 0x405cc700, encoding = 0xa0ce928 "UTF-8", read_cd = 0xffffffff, write_cd = 0xffffffff, line_term = 0x0, line_term_len = 0, buf_size = 1024, read_buf = 0x0, encoded_read_buf = 0x0, write_buf = 0x0, partial_write_buf = "\0\00\0\0", use_buffer = 1, do_encode = 0, close_on_unref = 0, is_readable = 1, is_writeable = 0, is_seekable = 0, reserved1 = 0x0, reserved2 = 0x0} (gdb) print *(nsIEventQueue *)data $11 = {<nsIEventTarget> = {<nsISupports> = { _vptr.nsISupports = 0x7008c}, <No data fields>}, <No data fields>} Guessing component from the stack. I'm running heavily patched RH 7.3, gtk2-2.4.1, Xft-2.2-0.ximian.4.5. I couldn't find any pattern in crashes, though they always happen when some page is loading. I'm eager to provide additional info if needed. Reproducible: Sometimes Steps to Reproduce:
Updated•20 years ago
|
Keywords: talkbackid
Whiteboard: tb1950323M
Comment 1•20 years ago
|
||
do the crashes perhaps happen when Mozilla is opening a new window (popup)? You can fetch your own talkback data at http://talkback-public.mozilla.org/ Did you add talkback to your own build (that doesn't work)?
Keywords: talkbackid
Whiteboard: tb1950323M
> do the crashes perhaps happen when Mozilla is opening a new window (popup)? Can't say for sure. I am under impression that no popups are involved. At least there's no visual indication of new popup, no window outline, etc. > You can fetch your own talkback data at http://talkback-public.mozilla.org/ I'm aware of talkback server, however the captured incident data didn't contain source file info. Thats why I rebuilt the tree with debug info. > Did you add talkback to your own build (that doesn't work)? Yes, I described the procedure - install talkback.xpi from nightle trunk build and replace BuildID with your real build date. I believe this is enough to get talkback wired, am I right?
Comment 3•20 years ago
|
||
no. each talkback.xpi will only work with the binary build it's associated with. if you want symbol data from your own build, you'll need to build without --enable-strip and then --enable-optimize="-g -O" or --enable-debug for full symbols. But the stack you pasted into comment 0 is sufficient. I think you're seeing bug 269585.
Keywords: crash
> if you want symbol data from your own build, you'll need to build without --enable-strip and then --enable-optimize="-g -O" or --enable-debug for full symbols. Thats what I did. I've got two more stacks. First, crash just after new popup window was opened manually (by clicking link with javascript open function). So it's certainly related to bug 269585. Gdb couldn't figure out the culprit though: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 21367)] 0x797a3a3f in ?? () (gdb) bt #0 0x797a3a3f in ?? () #1 0x405993cc in g_io_unix_dispatch () from /usr/lib/libglib-2.0.so.0 #2 0x40576cdc in g_main_dispatch () from /usr/lib/libglib-2.0.so.0 #3 0x40577bc7 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #4 0x40577fb5 in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0 #5 0x405785ee in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #6 0x402a6185 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #7 0x40eea306 in nsAppShell::Run() (this=0x8116f48) at nsAppShell.cpp:142 #8 0x40e4cda4 in nsAppStartup::Run() (this=0xa781668) at nsCOMPtr.h:711 #9 0x0804cf21 in _init () #10 0x0804da0f in _init () #11 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6 Second crash happened after I did "compact folders" in mail/news file menu: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 6813)] 0x00000000 in ?? () (gdb) where #0 0x00000000 in ?? () #1 0x40ee9ed5 in event_processor_callback (source=0x8baf320, condition=1089380032, data=0x8baf240) at nsAppShell.cpp:67 #2 0x405993cc in g_io_unix_dispatch () from /usr/lib/libglib-2.0.so.0 #3 0x40576cdc in g_main_dispatch () from /usr/lib/libglib-2.0.so.0 #4 0x40577bc7 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #5 0x40577fb5 in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0 #6 0x405785ee in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #7 0x402a6185 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #8 0x40eea306 in nsAppShell::Run() (this=0x8116f48) at nsAppShell.cpp:142 #9 0x40e4cda4 in nsAppStartup::Run() (this=0x9e7e7f0) at nsCOMPtr.h:711 #10 0x0804cf21 in _init () #11 0x0804da0f in _init () #12 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) frame 1 #1 0x40ee9ed5 in event_processor_callback (source=0x8baf320, condition=1089380032, data=0x8baf240) at nsAppShell.cpp:67 67 eventQueue->ProcessPendingEvents(); Current language: auto; currently c++ (gdb) print *source $1 = {ref_count = 146469736, funcs = 0x405cc2c4, encoding = 0x405cc6e0 "Т\222Y@@\223Y@p\223Y@Ю\223Y@", read_cd = 0x2, write_cd = 0x80784d0, line_term = 0xc8 <Address 0xc8 out of bounds>, line_term_len = 3, buf_size = 48736, read_buf = 0x86ae678, encoded_read_buf = 0x9df5840, write_buf = 0x0, partial_write_buf = "\0\0\0\0\0", use_buffer = 0, do_encode = 0, close_on_unref = 0, is_readable = 0, is_writeable = 0, is_seekable = 0, reserved1 = 0x28, reserved2 = 0x10001}
Comment 5•20 years ago
|
||
*** This bug has been marked as a duplicate of 269585 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Updated•16 years ago
|
Product: Core → Core Graveyard
Updated•13 years ago
|
Crash Signature: [@event_processor_callback() ]
You need to log in
before you can comment on or make changes to this bug.
Description
•