Skip site navigation (1)Skip section navigation (2) 
Date:      Wed, 13 Jul 2011 12:42:09 +0400
From:      Pan Tsu <inyaoo@gmail.com>
To:        freebsd-gecko@freebsd.org
Subject:   Re: [SVN-Commit] r588 - branches/experimental/www/firefox-aurora/files
Message-ID:  <86sjqapo66.fsf@gmail.com>
References:  <201107111015.p6BAFobk084287@trillian.chruetertee.ch>
next in thread | previous in thread | raw e-mail | index | archive | help 

svn-freebsd-gecko@chruetertee.ch writes:

> Author: flo
> Date: Mon Jul 11 10:15:50 2011
> New Revision: 588
>
> Log:
> readd patch to the correct file
>
> Submitted by:	Pan Tsu <inyaoo@gmail.com>
>
> Note, firefox-aurora is still completeley broken

Broken? Does it crash? Even when built WITH_DEBUG= ?
I for one get crashes on Minefield with non-debug builds after

  https://bugzilla.mozilla.org/show_bug.cgi?id=552864

Here is a trace from -O0 on gcc46

  (gdb) r
  Starting program: WRKSRC/dist/bin/firefox
  [New LWP 114014]
  [New Thread 801807400 (LWP 114014)]
  [New Thread 80180d000 (LWP 115932)]
  [New Thread 80180d800 (LWP 117459)]

  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 801807400 (LWP 114014)]
  0x0000000803626644 in nsNativeModuleLoader::LoadModule (this=Cannot access memory at address 0x7fffffbfee28
  )
      at WRKSRC/xpcom/components/nsNativeComponentLoader.cpp:132
  132     {

  (gdb) i th
    4 Thread 80180d800 (LWP 117459)  0x0000000801308b6c in _umtx_op_err ()
      at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
    3 Thread 80180d000 (LWP 115932)  0x0000000800936e8c in kevent () at kevent.S:3
  * 2 Thread 801807400 (LWP 114014)  0x0000000803626644 in nsNativeModuleLoader::LoadModule (this=Cannot access memory at address 0x7fffffbfee28
  )
      at WRKSRC/xpcom/components/nsNativeComponentLoader.cpp:132

  (gdb) bt
  #0  0x0000000803626644 in nsNativeModuleLoader::LoadModule (this=Cannot access memory at address 0x7fffffbfee28
  )
      at WRKSRC/xpcom/components/nsNativeComponentLoader.cpp:132
  #1  0x0000000803626621 in LoadModuleMainThreadRunnable::Run (this=0x80ffeb8b0)
      at WRKSRC/xpcom/components/nsNativeComponentLoader.cpp:121
  #2  0x0000000803629a43 in nsThreadSyncDispatch::Run (this=0x80ffeb8e0)
      at WRKSRC/xpcom/threads/nsThread.cpp:792
  #3  0x000000080362927f in nsThread::ProcessNextEvent (this=0x801b8eb00, mayWait=1, result=0x7fffffbff43c)
      at WRKSRC/xpcom/threads/nsThread.cpp:617
  #4  0x00000008035d3a6f in NS_ProcessNextEvent_P (thread=0x801b8eb00, mayWait=1)
      at WRKSRC/xpcom/build/nsThreadUtils.cpp:245
  #5  0x0000000803628c84 in nsThread::Dispatch (this=0x801b8eb00, event=0x80ffeb8b0, flags=1)
      at WRKSRC/xpcom/threads/nsThread.cpp:416
  #6  0x00000008035d38d6 in NS_DispatchToMainThread_P (event=0x80ffeb8b0, dispatchFlags=1)
      at WRKSRC/xpcom/build/nsThreadUtils.cpp:169

  #7  0x00000008036266b6 in nsNativeModuleLoader::LoadModule (this=0x80196bd10, aFile=0x801bd4980)
      at WRKSRC/xpcom/components/nsNativeComponentLoader.cpp:139
  [...]

Where frames #0-6 repeat a lot of times. Reverting the bug seems to fix it.

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86sjqapo66.fsf>