Closed Bug 269847 Opened 20 years ago Closed 20 years ago

[gtk2] Itermittent crashes [@event_processor_callback() ]

Categories

(Core Graveyard :: GFX: Gtk, defect)

x86
Linux
defect
Not set
normal

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:
Keywords: talkbackid
Whiteboard: tb1950323M
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?
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 "&#1058;\222Y@@\223Y@p\223Y@&#1070;\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}

*** This bug has been marked as a duplicate of 269585 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
Crash Signature: [@event_processor_callback() ]
You need to log in before you can comment on or make changes to this bug.