[SVN-Commit] r588 - branches/experimental/www/firefox-aurora/files

Pan Tsu inyaoo at gmail.com
Wed Jul 13 08:42:18 UTC 2011


svn-freebsd-gecko at 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 at 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.


More information about the freebsd-gecko mailing list