513932 - component registration and waiting on a condition variable (mac)

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Joel Reymont (:joelr)]

Is this a normal profile or something that should be investigated further?

I don't have enough experience with component registration to tell off the bat.

I ran Shark on Firefox until it came up and loaded the default page.

# Report 1 - Session 2 - Time Profile (All Thread States) of Everything
SharkProfileViewer
# Generated from the visible portion of the outline view
+ 87.4%, thread_start, libSystem.B.dylib
| + 87.3%, _pthread_start, libSystem.B.dylib
| | + 62.9%, PR_Select, libnspr4.dylib
| | | + 28.6%, NS_GetComponentRegistrar_P, XUL
| | | | + 28.6%, JNIEnv_::CallStaticObjectMethod(_jclass*, _jmethodID*, ...), XUL
| | | | | + 28.6%, NS_GetComponentRegistrar_P, XUL
| | | | | | + 22.9%, NS_GetComponentRegistrar_P, XUL
| | | | | | | + 17.2%, PR_Wait, libnspr4.dylib
| | | | | | | | + 17.2%, PR_WaitCondVar, libnspr4.dylib
| | | | | | | | | + 11.4%, pthread_cond_wait, libSystem.B.dylib
| | | | | | | | | | + 11.4%, _pthread_cond_wait, libSystem.B.dylib
| | | | | | | | | | |   11.4%, semaphore_wait_signal_trap, libSystem.B.dylib
| | | | | | | | | - 5.7%, PR_AssertCurrentThreadOwnsLock, libnspr4.dylib
| | | | | | | - 5.7%, PR_WaitCondVar, libnspr4.dylib
| | | | | | - 5.7%, 0xc30a0 [433B], XUL
| | | + 17.2%, 0xce980 [286B], XUL
| | | | + 17.2%, 0xcdd10 [210B], XUL
| | | | | + 17.2%, PR_WaitCondVar, libnspr4.dylib
| | | | | | + 17.2%, PR_AssertCurrentThreadOwnsLock, libnspr4.dylib
| | | | | | | + 17.2%, pthread_cond_timedwait, libSystem.B.dylib
| | | | | | | | + 17.2%, _pthread_cond_wait, libSystem.B.dylib
| | | | | | | | |   17.2%, semaphore_timedwait_signal_trap, libSystem.B.dylib
| | | - 5.7%, 0x829150 [304B], XUL
| | | - 5.7%, 0x827940 [581B], XUL
| | | - 5.7%, 0x4be23 [unknown], XUL
| | - 11.4%, 0x2184a4bf [unknown], Flash Player
| | - 5.7%, XRE_GetFileFromPath, XUL
| | - 5.7%, 0x21a72670 [264B], Flash Player
| | - 1.4%, TimerThread, CarbonCore
| |   0.0%, __pthread_set_self, libSystem.B.dylib
|   0.0%, __pthread_set_self, libSystem.B.dylib
- 6.9%, start_wqthread, libSystem.B.dylib
- 5.7%, start, firefox-bin
  0.1%, __bsdthread_terminate, libSystem.B.dylib

Comment 1

[Benjamin Smedberg]

This doesn't look like a build with good symbols: all your functions are being assigned to the closest exported symbol. Are you profiling a shark build or something else?

also, PR_AssertCurrentThreadOwnsLock shouldn't be called at all in release builds, only in debug builds with assertions.

Comment 2

[Joel Reymont (:joelr)]

This is my configuration. Is there a special Shark option? 

What should I change for Shark?

export CC="gcc-4.2 -arch i386"
export CXX="g++-4.2 -arch i386"
ac_add_options --target=i386-apple-darwin8.0.0
ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.5.sdk
ac_add_options --enable-macos-target=10.5

export HOST_CC="gcc-4.2"
export HOST_CXX="g++-4.2"
export RANLIB=ranlib
export AR=ar
export AS=$CC
export LD=ld
export STRIP="strip -x -S"
export CROSS_COMPILE=1
export MOZ_DEBUG_SYMBOLS=1

. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-release-profiling
mk_add_options MOZ_MAKE_FLAGS=-j2
ac_add_options --disable-tests
ac_add_options --disable-crashreporter
ac_add_options --enable-dtrace
ac_add_options --enable-libxul
ac_add_options --enable-optimize
ac_add_options --enable-debugger-info-modules

# mk_add_options AUTOCONF=autoconf213

Comment 3

[Joel Reymont (:joelr)]

Forgot to mention that this is Snow Leopard, 32-bit mode, 32-bit build. I had trouble with symbols on Leopard as well.

Comment 4

[Joel Reymont (:joelr)]

Ben, what do you mean by functions being assigned to the closest exported symbol?

Comment 5

[Benjamin Smedberg]

Use this:
export CC='gcc-4.2 -arch i386 -g'
export CXX='g++-4.2 -arch i386 -g'

Exported symbols are the symbols visible from outside of their shared library. All of the code from one exported symbol to the next are charged to the first in your profile, which is wrong and produces the weird profile stacks you see.

Comment 6

[Joel Reymont (:joelr)]

Got it fixed up now. Symbols were stripped during packaging.

Hopefully the last invalid bug from me!