1170039 - Startup crash in dosprintf

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Mats Palmgren (inactive)]

[Tracking Requested - why for this release]: topcrash in v41, recent regression

This bug was filed from the Socorro interface and is 
report bp-9f18f7ae-cc05-45f6-b9d7-f17522150530.
=============================================================

This signature is spiking in 41.0a1 Top Crash data. It's currently at #10.
It appears to have started in build 20150528030206.
All crashes occurs within a minute or so.

Regression range:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ff2e07228041&tochange=baa9c64fea6f

Stack:

dosprintf
JS_vsnprintf(char*, unsigned int, char const*, char*)
JS_snprintf(char*, unsigned int, char const*, ...)
js::gcstats::Statistics::formatJsonDescription(unsigned __int64)
js::gcstats::Statistics::formatJsonMessage(unsigned __int64)
JS::GCDescription::formatJSON(JSRuntime*, unsigned __int64)
DOMGCSliceCallback
js::gcstats::Statistics::endSlice()
js::gc::GCRuntime::collect(bool, js::SliceBudget, JS::gcreason::Reason)
js::gc::GCRuntime::gcSlice(JS::gcreason::Reason, __int64)
nsJSContext::GarbageCollectNow(JS::gcreason::Reason, nsJSContext::IsIncremental, nsJSContext::IsShrinking, __int64)
InterSliceGCTimerFired(nsITimer*, void*)
nsTimerImpl::Fire()
nsTimerEvent::Run()
nsThread::ProcessNextEvent(bool, bool*)
...

Comment 1

[Mats Palmgren (inactive)]

Given the stack and regression range, perhaps it's bug 1165410?

Comment 2

[Terrence Cole [:terrence]]

Seems likely. All current instances appear to be on windows, with memchaser installed. I've been testing in that configuration all morning without success.

Comment 3

[(Away)]

Definitely from bug 1165410. There are some printf format mismatches on 32-bit builds:

   buffer = char [1024] ""timestamp":1433003942239000,"max_pause":33.000,"total_time":731.000,...
   longest = 0n33731

max_pause should have been 33.731, but since (longest / 1000) and (longest % 1000) each got pushed as an int64_t, we're off by a couple words. Same for the other int64_t's. It blows up when we reach the %s.

I've got the file open already so I can take this.

Comment 4

[Terrence Cole [:terrence]]

Yup, just saw the same thing when looking at dosprintf.

Comment 5

[(Away)]

Attachment: Fix format specifiers

Comment 6

[Terrence Cole [:terrence]]

Comment on attachment 8613623 [details] [diff] [review]
Fix format specifiers

Review of attachment 8613623 [details] [diff] [review]:
-----------------------------------------------------------------

\o/ Thanks!

Comment 7

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/eced3077126b

Comment 8

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/eced3077126b

Comment 9

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Adding a tracking flag for FF41. Also requesting QE team to verify the fix if this is easy to reproduce.

Comment 10

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Kairo, while adding a tracking flag for this bug, I noticed that we are still hitting this crash signature in the last one week. Do we need to re-open this bug? Thanks!

Comment 11

[Robert Kaiser]

(In reply to Ritu Kothari (:ritu) from comment #10)
> Kairo, while adding a tracking flag for this bug, I noticed that we are
> still hitting this crash signature in the last one week. Do we need to
> re-open this bug? Thanks!

I don't see any crashes with 41 or newer, so I think the fix seems to have worked, and that should be enough for verification as well.