very long hangs - lots of JSLL_MinInt

RESOLVED INCOMPLETE

Status

()

Core
JavaScript Engine
--
major
RESOLVED INCOMPLETE
10 years ago
6 years ago

People

(Reporter: Bill McGonigle (not currently reading bugmail; please contact directly), Unassigned)

Tracking

Trunk
x86
Mac OS X
Points:
---
Bug Flags:
blocking1.9 -
wanted1.9.0.x +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

Since 3.0b5 I've been seeing frequent hangs that eventually resolve after several minutes.  Sample shows lots of JSLL_MinInt.   Attaching Sample.

Extensions: NoScript, FireBug, FlashGot, Tamper Data.
Created attachment 314022 [details]
OSX Sample during hang (zipped)
JSLL_MinInt is wrong, symbol round-down -- but why are we even linking that in? We don't need long long emulation. Crowder, can you nm around and see why this is defined and exported?

/be
Flags: blocking1.9?
If you're on Leopard, could you try the Shark-ready builds at ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/shark-10.5/ and get another sample?  That'll have more useful symbols for us.  (ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/shark/ may work on 10.4, but I haven't tested myself.)

Comment 4

10 years ago
Looks like we're providing it on purpose, no nm needed.

JS_PUBLIC_API(JSInt64) JSLL_MinInt(void) { return ll_minint; }

Been there since version 3.1 at least.

Comment 5

10 years ago
Here's what nearby symbols look like in the shark build shaver provided:

00026416 t _InternalError
0007af75 t _IsFunctionQName
0003bd66 t _Iterator
0003b85e t _IteratorNextImpl
0003dc77 T _JSLL_MaxInt
0003dc8e T _JSLL_MinInt
0003dc60 T _JSLL_Zero
0000624b T _JS_AddArgumentFormatter
00001d76 T _JS_AddExternalStringFinalizer
00001b7e T _JS_AddNamedRoot
00001b5a T _JS_AddNamedRootRT
-'ing this as we don't have information on how frequently this is hit.  Please re-nom if you disagree and believe that if this were the last JS bug, you would block the 1.9 release.

wanted1.9.0.x+
Flags: wanted1.9.0.x+
Flags: blocking1.9?
Flags: blocking1.9-

Updated

10 years ago
Blocks: 428128

Comment 7

10 years ago
Bill:  Were you able to again reproduce this bug?

Comment 8

10 years ago
Needs changes in jsd_step.c, also, that patch 
No longer blocks: 428128

Comment 9

10 years ago
Woops, ignore comment #8, just wanted the dependency changes.
Created attachment 316883 [details]
another Sample

This recurred again today, so I grabbed another Sample.  Tamper Data has been disabled since I last reported.  I still don't have a sure-fire way to reproduce this.  Running on Tiger here, Minefield as of the auto-update version of yesterday (2008-04-21 - sorry it's hung at the moment and I want to wait for it so I can quit it gracefully so it'll save my session).
Created attachment 317181 [details]
non-recursive high-CPU JSLL_MinInt

Got another hang today, but the call trace looks much different - still high CPU in JSLL_MinInt, but without the recursive-looking aspect of the previous two.

Build identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008041804 Minefield/3.0pre
Unfortunately, unless you're using a build with more symbols, the stack is virtually useless.  (JS_LLMinInt doesn't call any functions, and is extremely simple, so any stack that includes it is very likely to be incorrect.)

If you re-enable your extensions and use the shark build I referenced above (ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/shark/), do you get a better sample?

I really wish we had a way to trigger Breakpad from outside the app, so that you could get us a crash report on this, but apparently that would be in violation of the strictures of Mach signal purity or something.
Shebs said that Breakpad could probably register a signal handler in parallel to its mach exception handler, so that we could handle signals, but that's obviously not going to make 1.9. Its only utility (afaict) would be to allow users to use `kill` to trigger Breakpad, since real crashes give us mach exceptions.
(In reply to comment #12)
> If you re-enable your extensions and use the shark build I referenced above
> (ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/shark/), do
> you get a better sample?

I'm running it now (found a fast Internet connection...) and will post here if I can catch this in the act.  I also posted bug 430478 since downloading the Shark build.  I thought they were separate issues, but since you mention that this stack is likely incorrect, could they be related?  The symptoms are similar, but I'm not able to make any determinations beyond that.

Comment 15

8 years ago
(In reply to comment #12)
> Unfortunately, unless you're using a build with more symbols, the stack is
> virtually useless.  (JS_LLMinInt doesn't call any functions, and is extremely
> simple, so any stack that includes it is very likely to be incorrect.)
> 
> If you re-enable your extensions and use the shark build I referenced above
> (ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/shark/), do
> you get a better sample?

Bill, still see this?

Comment 16

7 years ago
Bill, doesn't look like there's anything actionable here, based on comment 14 and comment 12. Or at least needs a new trace.  Is that correct?
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.