773308 - Awesomebar and other activities hang when profiling

Status: RESOLVED DUPLICATE of bug 791640

(Core :: Gecko Profiler, defect)

Description

[Benoit Girard (:BenWa)]

STR:
1) Start profiler until any configuration
2) Bring up awesomebar

Comment 1

[Julian Seward [:jseward]]

Then you get:

I/ActivityManager(  148): START {flg=0x40010000 cmp=org.mozilla.fennec_sewardj/org.mozilla.gecko.AwesomeBar (has extras)} from pid 32519

# the awesomebar is indeed created, but ..

W/ActivityManager(  148): Launch timeout has expired, giving up wake lock!
W/ActivityManager(  148): Activity idle timeout for ActivityRecord{411fd618 org.mozilla.fennec_sewardj/org.mozilla.gecko.AwesomeBar}

--------------

By removing parts of the signal handler, I discovered that the hang happens
even if the (sigprof) signal handler is completely empty, and does nothing.

Comment 2

[Julian Seward [:jseward]]

(In reply to Julian Seward from comment #1)
> By removing parts of the signal handler, I discovered that the hang happens
> even if the (sigprof) signal handler is completely empty, and does nothing.

.. from which I am inclined to believe that something that has to do with
activities is getting screwed up by having SIGPROFs thrown at it.  No idea
where to start looking, though.

Comment 3

[Julian Seward [:jseward]]

I should add: I looked at a number of stack-sets from about 5 different hangs,
and looked at the mutexes and CVs (pthread_ level) involved in the hung set of
threads.  I didn't see any duplicates, so it doesn't seem like the hang involves
lock cycles.

Although Fennec as a whole hangs, both the signal-sending thread and the
signal-receiving thread are alive, sending signals and taking samples respectively.

Comment 4

[Benoit Girard (:BenWa)]

CCing glandium who believes this is either related to SIGPROF or the use of our tracing event.

Comment 5

[Mike Hommey [:glandium]]

(In reply to Benoit Girard (:BenWa) from comment #4)
> CCing glandium who believes this is either related to SIGPROF or the use of
> our tracing event.

I'm now convinced it *is* the event tracer. Bug 791640