Closed Bug 427472 Opened 16 years ago Closed 13 years ago

very long hangs - lots of JSLL_MinInt

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
major

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: bill+mozilla-bugzilla, Unassigned)

Details

Attachments

(3 files)

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.
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.)
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.
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-
Blocks: 428128
Bill:  Were you able to again reproduce this bug?
Needs changes in jsd_step.c, also, that patch 
No longer blocks: 428128
Woops, ignore comment #8, just wanted the dependency changes.
Attached file 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).
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.
(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?
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
Closed: 13 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: