Check if we can end up having MessagePumpForNonMainThreads::Run on the main thread stack
Categories
(Core :: IPC, task)
Tracking
()
People
(Reporter: jstutte, Unassigned)
References
(Blocks 1 open bug)
Details
From this hang it seems we have a mozilla::ipc::MessagePumpForNonMainThreads::Run call on the main thread stack, which is probably not expected?
We also seem to execute some idle tasks, we might want to avoid this if we are expecting shutdown? I am also puzzled by the MOZ_ASSERT(!didIdleWork); there which seems to tell us that we never expect to do idle work on non-main threads (but why are we calling it then?)...
|
||
Comment 1•2 years ago
|
||
That was obtained from stack scanning, which isn't entirely trustworthy — it just means that the address was found in stack memory. In general there are other ways an address could end up there, like function pointer in a local variable. In this case the address seems to point into the middle of a function, so that's probably not it, and it might be valid in this case, but it's worth keeping in mind if something that seems impossible shows up with scan in the trust column.
|
Reporter | |
Comment 2•2 years ago
|
||
(In reply to Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧ from comment #1)
That was obtained from stack scanning, which isn't entirely trustworthy — it just means that the address was found in stack memory. In general there are other ways an address could end up there, like function pointer in a local variable. In this case the address seems to point into the middle of a function, so that's probably not it, and it might be valid in this case, but it's worth keeping in mind if something that seems impossible shows up with
scanin the trust column.
I tried to open the dump with Visual Studio, but it showed me no stack at all. That might hint to a broken dump? (I also have the gut feeling that after the latest VS updates things are less reliable in general)
Description
•