epiphany-gecko crashed with SIGSEGV in __kernel_vsyscall()

Bug #191052 reported by Rich
16
Affects Status Importance Assigned to Milestone
xulrunner-1.9 (Ubuntu)
Invalid
Medium
Alexander Sack

Bug Description

Binary package hint: epiphany-browser

I opened epiphany, tried to browse a site, closed it via alt-f4, and it apparently crashed on the way out.

ProblemType: Crash
Architecture: i386
CrashCounter: 1
Date: Mon Feb 11 14:09:27 2008
DistroRelease: Ubuntu 8.04
ExecutablePath: /usr/bin/epiphany-gecko
NonfreeKernelModules: nvidia
Package: epiphany-gecko 2.21.90-0ubuntu2
PackageArchitecture: i386
ProcCmdline: epiphany-browser
ProcCwd: /home/rich
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
 LANG=en_US.UTF-8
 SHELL=/bin/bash
Signal: 11
SourcePackage: epiphany-browser
StacktraceTop:
 __kernel_vsyscall ()
 raise () from /lib/tls/i686/cmov/libpthread.so.0
 ?? () from /usr/lib/xulrunner-1.9b3pre/libxul.so
 ?? ()
 ?? ()
Title: epiphany-gecko crashed with SIGSEGV in __kernel_vsyscall()
Uname: Linux eris 2.6.24-7-generic #1 SMP Thu Feb 7 01:29:58 UTC 2008 i686 GNU/Linux
UserGroups: adm admin audio cdrom dialout dip floppy fuse lpadmin plugdev pulse pulse-access pulse-rt scanner src video

Tags: apport-crash
Revision history for this message
Rich (rincebrain) wrote :
Revision history for this message
Apport retracing service (apport) wrote : Symbolic stack trace

StacktraceTop:?? ()
NS_HasPendingEvents_P (thread=0x82f1f60)
nsBaseAppShell::OnProcessNextEvent (this=0x85ab7a8,
nsThread::ProcessNextEvent (this=0x82f1f60, mayWait=0,
NS_ProcessPendingEvents_P (thread=0x82f1f60, timeout=20)

Revision history for this message
Apport retracing service (apport) wrote : Symbolic threaded stack trace
Revision history for this message
Apport retracing service (apport) wrote : Stack trace with source code
Revision history for this message
Pedro Villavicencio (pedro) wrote :

Thanks for your bug report. Please try to obtain a backtrace http://wiki.ubuntu.com/DebuggingProgramCrash and attach the file to the bug report. This will greatly help us in tracking down your problem.

Changed in epiphany-browser:
assignee: nobody → desktop-bugs
importance: Undecided → Medium
status: New → Incomplete
Revision history for this message
Andrea Corbellini (andrea.corbellini) wrote :

Here's a complete backtrace. It happened to me when browsing page information, but it segfaults in the same function.

Changed in epiphany-browser:
assignee: desktop-bugs → nobody
status: Incomplete → New
Revision history for this message
Sebastien Bacher (seb128) wrote :

Confirming the issue

Changed in xulrunner-1.9:
status: New → Confirmed
Revision history for this message
Sebastien Bacher (seb128) wrote :
Download full text (8.4 KiB)

epiphany-browser also has sometimes blocked background instance, seems to be on closing too

"Thread 7 (Thread 0xb5a01b90 (LWP 19054)):
#0 0xb7efb410 in __kernel_vsyscall ()
#1 0xb7140aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7eb2821 in PR_WaitCondVar (cvar=0x945df88, timeout=4294967295) at ptsynch.c:405
#3 0xb7eb2887 in PR_Wait (mon=0x8a66cb8, timeout=4294967295) at ptsynch.c:584
#4 0xb5e7576d in nsAutoMonitor::Wait (this=0xb5a00d08, interval=4294967295) at ../../dist/include/xpcom/nsAutoLock.h:340
#5 0xb65976c4 in nsEventQueue::GetEvent (this=0x8a5cde8, mayWait=1, result=0xb5a00d44) at nsEventQueue.cpp:85
#6 0xb6598aba in nsThread::ProcessNextEvent (this=0x8268318, mayWait=1, result=0xb5a00d84) at nsThread.cpp:501
#7 0xb6567cc3 in NS_ProcessNextEvent_P (thread=0x80, mayWait=1) at nsThreadUtils.cpp:227
#8 0xb659d3e3 in nsProxyEventObject::CallMethod (this=0x8a5a3a0, methodIndex=<value optimized out>,
    methodInfo=0x81df820, params=0xb5a00e10) at nsProxyEventObject.cpp:259
#9 0xb65a552f in PrepareAndDispatch (methodIndex=<value optimized out>, self=0x917c150, args=0xb5a00ebc)
    at xptcstubs_gcc_x86_unix.cpp:95
#10 0xb65645a9 in nsGetInterface::operator() (this=0xb5a00f30, aIID=@0xb66db5a4, aInstancePtr=0xb5a00efc)
    at nsIInterfaceRequestorUtils.cpp:52
#11 0xb6563111 in nsCOMPtr_base::assign_from_helper (this=0xb5a00f60, helper=@0xfffffe00, iid=@0x1) at nsCOMPtr.cpp:150
#12 0xb63b035f in nsNSSSocketInfo::SetNotificationCallbacks (this=0x8a8de30, aCallbacks=0x9012c94) at nsNSSIOLayer.cpp:339
#13 0xb5e30ba4 in nsSocketTransport::BuildSocket (this=0x9460200, fd=@0xb5a01048, proxyTransparent=@0xb5a01044,
    usingSSL=@0xb5a01040) at nsSocketTransport2.cpp:1042
#14 0xb5e30eb5 in nsSocketTransport::InitiateSocket (this=0x9460200) at nsSocketTransport2.cpp:1110
#15 0xb5e313dd in nsSocketTransport::OnSocketEvent (this=0x9460200, type=1, status=0, param=0x8293df8)
    at nsSocketTransport2.cpp:1430
#16 0xb5e332f8 in nsSocketEvent::Run (this=0x8ee33a8) at nsSocketTransport2.cpp:98
#17 0xb6598ae6 in nsThread::ProcessNextEvent (this=0x8268318, mayWait=0, result=0xb5a01238) at nsThread.cpp:510
#18 0xb6567d6b in NS_ProcessPendingEvents_P (thread=0x8268318, timeout=4294967295) at nsThreadUtils.cpp:180
#19 0xb5e33dbc in nsSocketTransportService::Run (this=0x8267ab8) at nsSocketTransportService2.cpp:555
#20 0xb6598ae6 in nsThread::ProcessNextEvent (this=0x8268318, mayWait=1, result=0xb5a012f4) at nsThread.cpp:510
#21 0xb6567cc3 in NS_ProcessNextEvent_P (thread=0x80, mayWait=1) at nsThreadUtils.cpp:227
#22 0xb659877c in nsThread::ThreadFunc (arg=0x8268318) at nsThread.cpp:254
#23 0xb7eb87fa in _pt_root (arg=0x82684f8) at ptthread.c:221
#24 0xb713c4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#25 0xb6ea1d4e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 6 (Thread 0xb3560b90 (LWP 19057)):
#0 0xb7efb410 in __kernel_vsyscall ()
#1 0xb7140dd2 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7eb1965 in pt_TimedWait (cv=0x81db474, ml=0x81db410, timeout=869552) at ptsynch.c:280
#3 0xb7eb2791 in PR_WaitCondVar (cvar=0x81db470, timeout=869552...

Read more...

Revision history for this message
Alexander Sack (asac) wrote :

adding soft milestone for now so it stays on my radar.

Changed in xulrunner-1.9:
milestone: none → ubuntu-8.04
Alexander Sack (asac)
Changed in xulrunner-1.9:
assignee: nobody → asac
Revision history for this message
Alexander Sack (asac) wrote :

Do you still see this crash with latest xulrunner in archive? (please don't upgrade to latest cairo which is known to cause crashes independently from this).

Revision history for this message
Alexander Sack (asac) wrote :

moving back to 8.04.1 as its uncertain that we still see this at all.

Changed in xulrunner-1.9:
milestone: ubuntu-8.04 → ubuntu-8.04.1
Revision history for this message
Steve Langasek (vorlon) wrote :

no feedback for > 1 month. Marking 'incomplete' and dropping the milestone; we might presume this is 'fix released', but I'll leave that to Alexander to decide.

Changed in xulrunner-1.9:
milestone: ubuntu-8.04.1 → none
status: Confirmed → Incomplete
Revision history for this message
Andrea Corbellini (andrea.corbellini) wrote :

I didn't read Alexander's question for mistake, sorry. This bug seems fixed with the latest xulrunner so I mark it Fix Released.

Changed in xulrunner-1.9:
status: Incomplete → Fix Released
Revision history for this message
Sebastien Bacher (seb128) wrote :

got the same crash in current intrepid today, reopening the bug

Changed in xulrunner-1.9:
status: Fix Released → New
Revision history for this message
Sebastien Bacher (seb128) wrote :

not sure that's the same issue though, I'll rather open a new bug

Changed in xulrunner-1.9:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.