SIGPIPE in pt_Send (libnspr4)

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

SIGPIPE in pt_Send (libnspr4)

Greg Steuck
I am running i386-current-Feb-14. Firefox frequently crashes on me with
a stack trace below. Does anybody know if this has been fixed in newer
current (which I should upgrade to anyway, but not tonight). The relvant
packages are from Feb 14 snapshot: mozilla-firefox-2.0.0.1p0 nss-3.11.4p1

(gdb) run
Starting program: /usr/local/mozilla-firefox/firefox-bin
[New process 21520]
[New process 21520, thread 0x856dd800]
[New process 21520, thread 0x7d86e400]
[New process 21520, thread 0x7d970000]

Program received signal SIGPIPE, Broken pipe.
[Switching to process 21520, thread 0x7d970000]
0x0b2894e9 in sendto () from /usr/lib/libc.so.40.3
(gdb) where
#0  0x0b2894e9 in sendto () from /usr/lib/libc.so.40.3
#1  0x0def0856 in sendto (fd=35, msg=0x89157000, len=23, flags=0, to=0x0, to_len=0)
    at /usr/src/lib/libpthread/uthread/uthread_sendto.c:52
#2  0x0b2bee38 in send (s=35, msg=0x89157000, len=23, flags=0) at /usr/src/lib/libc/net/send.c:39
#3  0x0b0d47c9 in pt_Send () from /usr/local/mozilla-firefox/libnspr4.so.18.0
#4  0x0971ed5a in ssl_DefSend () from /usr/local/lib/libssl3.so.19.0
#5  0x0971239e in ssl3_SendRecord () from /usr/local/lib/libssl3.so.19.0
#6  0x097127be in SSL3_SendAlert () from /usr/local/lib/libssl3.so.19.0
#7  0x0972103a in ssl_SecureClose () from /usr/local/lib/libssl3.so.19.0
#8  0x09725297 in ssl_Close () from /usr/local/lib/libssl3.so.19.0
#9  0x0e2ae1fc in nsNSSSocketInfo::CloseSocketAndDestroy() () from /usr/local/mozilla-firefox/components/libpipnss.so.19.0
#10 0x0e2a1e9b in nsSSLThread::requestClose(nsNSSSocketInfo*) () from /usr/local/mozilla-firefox/components/libpipnss.so.19.0
#11 0x0e2ae192 in nsSSLIOLayerClose(PRFileDesc*) () from /usr/local/mozilla-firefox/components/libpipnss.so.19.0
#12 0x0b0c2a56 in PR_Close () from /usr/local/mozilla-firefox/libnspr4.so.18.0
#13 0x0d6d3165 in nsSocketTransport::ReleaseFD_Locked(PRFileDesc*) () from /usr/local/mozilla-firefox/components/libnecko.so.19.0
#14 0x0d6d36a2 in nsSocketTransport::OnSocketDetached(PRFileDesc*) () from /usr/local/mozilla-firefox/components/libnecko.so.19.0
#15 0x0d6d46ec in nsSocketTransportService::DetachSocket(nsSocketTransportService::SocketContext*) ()
   from /usr/local/mozilla-firefox/components/libnecko.so.19.0
#16 0x0d6d518b in nsSocketTransportService::Run() () from /usr/local/mozilla-firefox/components/libnecko.so.19.0
#17 0x0af5ffdb in nsThread::Main(void*) () from /usr/local/mozilla-firefox/libxpcom_core.so.19.0
#18 0x0b0d6a37 in _pt_root () from /usr/local/mozilla-firefox/libnspr4.so.18.0
#19 0x0deecfcb in _thread_start () at /usr/src/lib/libpthread/uthread/uthread_create.c:244
#20 0x0000001f in ?? ()
#21 0x00000000 in ?? ()
--
nest.cx is Gmail hosted, use PGP for anything private
Key: http://tinyurl.com/ho8qg 5E2B 2D0E 1E03 2046 BEC3  4D50 0B15 42BD 8DF5 A1B0

Reply | Threaded
Open this post in threaded view
|

Re: SIGPIPE in pt_Send (libnspr4)

Martynas Venckus-2
Please pkg_delete -F ambiguous .libs-mozilla-firefox, or something like that.

--
Martynas Venckus

Reply | Threaded
Open this post in threaded view
|

Re: SIGPIPE in pt_Send (libnspr4)

Kurt Miller-4
In reply to this post by Greg Steuck
On Monday 05 March 2007 2:38:19 am Gregory Steuck wrote:

> I am running i386-current-Feb-14. Firefox frequently crashes on me with
> a stack trace below. Does anybody know if this has been fixed in newer
> current (which I should upgrade to anyway, but not tonight). The relvant
> packages are from Feb 14 snapshot: mozilla-firefox-2.0.0.1p0 nss-3.11.4p1
>
> (gdb) run
> Starting program: /usr/local/mozilla-firefox/firefox-bin
> [New process 21520]
> [New process 21520, thread 0x856dd800]
> [New process 21520, thread 0x7d86e400]
> [New process 21520, thread 0x7d970000]
>
> Program received signal SIGPIPE, Broken pipe.
> [Switching to process 21520, thread 0x7d970000]
> 0x0b2894e9 in sendto () from /usr/lib/libc.so.40.3

SIPPIPE is normal. Issue the following command before
'run' to tell gdb to let them be handled/ignored by
firefox (i.e. SIG_IGN) without interrupting the debug
session.

(gdb) handle SIGPIPE nostop noprint

-Kurt

Reply | Threaded
Open this post in threaded view
|

SIGSEGV in nsFrameManager::GetPrimaryFrameFor in mozilla-firefox-2.0.0.1p0 (was: SIGPIPE in pt_Send (libnspr4))

Greg Steuck
>>>>> "Kurt" == Kurt Miller <[hidden email]> writes:

    >> I am running i386-current-Feb-14. Firefox frequently crashes on
    >> me with a stack trace below. Does anybody know if this has been
    >> fixed in newer current (which I should upgrade to anyway, but not
    >> tonight). The relvant packages are from Feb 14 snapshot:
    >> mozilla-firefox-2.0.0.1p0 nss-3.11.4p1
    >>
    >> (gdb) run Starting program:
    >> /usr/local/mozilla-firefox/firefox-bin [New process 21520] [New
    >> process 21520, thread 0x856dd800] [New process 21520, thread
    >> 0x7d86e400] [New process 21520, thread 0x7d970000]
    >>
    >> Program received signal SIGPIPE, Broken pipe.  [Switching to
    >> process 21520, thread 0x7d970000] 0x0b2894e9 in sendto () from
    >> /usr/lib/libc.so.40.3

    Kurt> SIPPIPE is normal. Issue the following command before 'run' to
    Kurt> tell gdb to let them be handled/ignored by firefox
    Kurt> (i.e. SIG_IGN) without interrupting the debug session.

    Kurt> (gdb) handle SIGPIPE nostop noprint

Blush. Yes, SIGPIPE was bogus. But there are crashes and this is one I
caught:

[New process 12726, thread 0x82258400]

Program received signal SIGPIPE, Broken pipe.

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 12726, thread 0x8a21b000]
0x0c9c6b42 in nsFrameManager::GetPrimaryFrameFor(nsIContent*) () from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
(gdb) where
#0  0x0c9c6b42 in nsFrameManager::GetPrimaryFrameFor(nsIContent*) () from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#1  0x0c9d6311 in PresShell::GetPrimaryFrameFor(nsIContent*, nsIFrame**) const ()
   from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#2  0x0cafa17b in nsPopupSetFrame::RepositionPopup(nsPopupFrameList*, nsBoxLayoutState&) ()
   from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#3  0x0caf9fc7 in nsPopupSetFrame::DoLayout(nsBoxLayoutState&) () from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#4  0x0cad14fb in nsIFrame::Layout(nsBoxLayoutState&) () from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#5  0x0cad67b2 in nsSprocketLayout::Layout(nsIFrame*, nsBoxLayoutState&) ()
   from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#6  0x0cad3fe0 in nsBoxFrame::DoLayout(nsBoxLayoutState&) () from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#7  0x0cad14fb in nsIFrame::Layout(nsBoxLayoutState&) () from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#8  0x0cad901a in nsStackLayout::Layout(nsIFrame*, nsBoxLayoutState&) () from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#9  0x0cad3fe0 in nsBoxFrame::DoLayout(nsBoxLayoutState&) () from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#10 0x0cad14fb in nsIFrame::Layout(nsBoxLayoutState&) () from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#11 0x0cad3a7f in nsBoxFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned&) ()
   from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#12 0x0cad02ba in nsRootBoxFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned&) ()
   from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#13 0x0c9efeec in nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned, unsigned&) () from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#14 0x0ca3b2eb in ViewportFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned&) ()
   from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#15 0x0c9ce07c in IncrementalReflow::Dispatch(nsPresContext*, nsHTMLReflowMetrics&, nsSize const&, nsIRenderingContext&) ()
   from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#16 0x0c9d8278 in PresShell::ProcessReflowCommands(int) () from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#17 0x0c9d7843 in PresShell::WillPaint() () from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#18 0x0cc4f278 in nsViewManager::FlushPendingInvalidates() () from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#19 0x0cc4d7f8 in nsViewManager::EnableRefresh(unsigned) () from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#20 0x0cc4d88c in nsViewManager::EndUpdateViewBatch(unsigned) () from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#21 0x0c9b2fcd in nsCSSFrameConstructor::RestyleEvent::HandleEvent() () from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#22 0x0c9b2ff0 in HandleRestyleEvent(PLEvent*) () from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
#23 0x0ecca608 in PL_HandleEvent () from /usr/local/mozilla-firefox/libxpcom_core.so.19.0
#24 0x0ecca54f in PL_ProcessPendingEvents () from /usr/local/mozilla-firefox/libxpcom_core.so.19.0
#25 0x0eccbc3d in nsEventQueueImpl::ProcessPendingEvents() () from /usr/local/mozilla-firefox/libxpcom_core.so.19.0
#26 0x099f03b0 in event_processor_callback(_GIOChannel*, GIOCondition, void*) ()
   from /usr/local/mozilla-firefox/components/libwidget_gtk2.so.19.0
#27 0x069e850b in g_vasprintf () from /usr/local/lib/libglib-2.0.so.1000.3
#28 0x069c59c4 in g_main_depth () from /usr/local/lib/libglib-2.0.so.1000.3
#29 0x069c699d in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.1000.3
#30 0x069c6cc2 in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.1000.3
#31 0x069c71ce in g_main_loop_run () from /usr/local/lib/libglib-2.0.so.1000.3
#32 0x0eb213b7 in gtk_main () from /usr/local/lib/libgtk-x11-2.0.so.802.1
#33 0x099f0703 in nsAppShell::Run() () from /usr/local/mozilla-firefox/components/libwidget_gtk2.so.19.0
#34 0x04d919a0 in nsAppStartup::Run() () from /usr/local/mozilla-firefox/components/libtoolkitcomps.so.19.0
#35 0x1c0087d8 in nsXULAppInfo::GetXPCOMABI(nsACString_internal&) ()
#36 0x1c003fb2 in __register_frame_info ()

--
nest.cx is Gmail hosted, use PGP for anything private
Key: http://tinyurl.com/ho8qg 5E2B 2D0E 1E03 2046 BEC3  4D50 0B15 42BD 8DF5 A1B0

Reply | Threaded
Open this post in threaded view
|

Re: SIGSEGV in nsFrameManager::GetPrimaryFrameFor in mozilla-firefox-2.0.0.1p0 (was: SIGPIPE in pt_Send (libnspr4))

Kurt Miller-4
On Tuesday 06 March 2007 1:37:33 am Gregory Steuck wrote:

> But there are crashes and this is one I caught:
>
> [New process 12726, thread 0x82258400]
>
> Program received signal SIGPIPE, Broken pipe.
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to process 12726, thread 0x8a21b000]
> 0x0c9c6b42 in nsFrameManager::GetPrimaryFrameFor(nsIContent*) () from /usr/local/mozilla-firefox/components/libgklayout.so.19.0
> (gdb) where
> #0  0x0c9c6b42 in nsFrameManager::GetPrimaryFrameFor(nsIContent*) () from /usr/local/mozilla-firefox/components/libgklayout.so.19.0

Ok now we're getting somewhere. :-)

I should have mentioned in my first email that you
should be running gdb on the -debug flavor package.
Running gdb on the non-debug pkg is helpful but with the
debug flavor you should get line numbers and they
really help the process along. ;-)

I looked briefly at GetPrimaryFrameFor() in
./mozilla/layout/base/nsFrameManager.cpp, but without
line numbers I can't make any progress. It can be any
number of null pointer de-refs or the like.

Here's what I suggest you do; Update your ports
tree to -current, make sure you have nspr-4.6.5
installed (to fix the issue Martynas pointed out),
build & install the debug flavor of firefox 2.0.0.2p1,
catch the segfault again.

Open a bug report at mozilla.org with the stack trace
with line numbers and include any other relevant
info like how to reproduce, architecture, ulimits, etc.
Send ports@ the link to the bug report and I'll add
whatever comments I can come up with to the bug report.

-Kurt