Crashing a lot when running with jprof

[dolphinling-2]

I'm trying to profile some stuff, and firefox is being very crashy when run with
jprof. The crashes only happen when profiling is actually happening, not when
it's paused. The console prints out a simple
./run-mozilla.sh: line 131:  6657 Segmentation fault      "$prog" ${1+"$@"}
when the crash happens.

I'm using the following .mozconfig:

. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@
ac_add_options --enable-optimize
ac_add_options --disable-debug
ac_add_options --enable-jprof

...and gcc 4.1.2 on Gentoo.

http://developer.mozilla.org/en/docs/Building_on_Fedora_Core_5 says to try
ac_add_options --enable-optimize="-O2 -fno-omit-frame-pointer"
I did, it didn't help.

Does anyone know what's wrong? Should I file a bug?

--
dolphinling
<http://dolphinling.net/>
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

[Mike Shaver]

On Wed, Feb 27, 2008 at 4:15 PM, dolphinling <lists@...> wrote:
> I'm trying to profile some stuff, and firefox is being very crashy when run with
>  jprof. The crashes only happen when profiling is actually happening, not when
>  it's paused. The console prints out a simple
>  ./run-mozilla.sh: line 131:  6657 Segmentation fault      "$prog" ${1+"$@"}
>  when the crash happens.

What's the stack?  (For jprof to be useful you'll need debugger info,
so you'll want to build with --enable-debugger-info-modules=yes
anyway.)

Mike
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

[L. David Baron]

On Wednesday 2008-02-27 16:15 -0500, dolphinling wrote:
> ...and gcc 4.1.2 on Gentoo.

i686 or x86_64?

> http://developer.mozilla.org/en/docs/Building_on_Fedora_Core_5 says to try
> ac_add_options --enable-optimize="-O2 -fno-omit-frame-pointer"
> I did, it didn't help.

It doesn't help if your system libraries are compiled with
-fomit-frame-pointer, which I think is likely to be the case on
x86_64.  (Although with gentoo maybe it's used everywhere.  Can you
check?)

And the glibc backtrace() stack walking code didn't work across
signal handlers, last I tried, so that wouldn't help here either.

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

[dolphinling-2]

L. David Baron wrote:
> On Wednesday 2008-02-27 16:15 -0500, dolphinling wrote:
>> ...and gcc 4.1.2 on Gentoo.
>
> i686 or x86_64?

i686

>> http://developer.mozilla.org/en/docs/Building_on_Fedora_Core_5 says to try
>> ac_add_options --enable-optimize="-O2 -fno-omit-frame-pointer"
>> I did, it didn't help.
>
> It doesn't help if your system libraries are compiled with
> -fomit-frame-pointer, which I think is likely to be the case on
> x86_64.  (Although with gentoo maybe it's used everywhere.  Can you
> check?)

They are (not by default, but it's one of the most common settings, since it's
mentioned in the handbook). I've run jprof successfully before though, a few
months ago--or at least, without it crashing, though the output seemed wrong.

>
> And the glibc backtrace() stack walking code didn't work across
> signal handlers, last I tried, so that wouldn't help here either.

This bit is over my head--is there something I can try contained in that sentence?


Mike Shaver wrote:
> What's the stack?  (For jprof to be useful you'll need debugger info,
> so you'll want to build with --enable-debugger-info-modules=yes
> anyway.)

Hmm, that's not mentioned on
http://developer.mozilla.org/en/docs/Setting_up_jprof--it just says you'll need
symbols. What would debugger info modules be needed for? If it's function names,
I do get those in very short profile runs that I stop before firefox crashes.



--
dolphinling
<http://dolphinling.net/>
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

[Boris Zbarsky]

dolphinling wrote:
> Hmm, that's not mentioned on
> http://developer.mozilla.org/en/docs/Setting_up_jprof--it just says
> you'll need symbols. What would debugger info modules be needed for?

Getting a useful stack out of gdb.  I don't think you actually need it for jprof.

If you do enable debugger-info-modules and then run with "-g" while profiling
and crash, then do "bt" to get the stack, what does it look like?

-Boris
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

[L. David Baron]

On Wednesday 2008-02-27 22:04 -0500, dolphinling wrote:
> L. David Baron wrote:
> > It doesn't help if your system libraries are compiled with
> > -fomit-frame-pointer, which I think is likely to be the case on
> > x86_64.  (Although with gentoo maybe it's used everywhere.  Can you
> > check?)
>
> They are (not by default, but it's one of the most common settings, since it's

Then jprof as written now isn't going to work for you, since it
depends on the frame pointer being saved in every stack frame for
stack traversal.

> > And the glibc backtrace() stack walking code didn't work across
> > signal handlers, last I tried, so that wouldn't help here either.
>
> This bit is over my head--is there something I can try contained in that sentence?

It's about a potential fix to jprof that I once tried but that
didn't work for me.  However, that fix would also seriously degrade
the performance characteristics of jprof since backtrace() is much
slower than jprof's frame pointer walking code.

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance