Closed Bug 1170039 Opened 5 years ago Closed 5 years ago

Startup crash in dosprintf

Categories

(Core :: JavaScript Engine, defect, critical)

41 Branch
x86
Windows NT
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla41
Tracking Status
firefox41 + verified

People

(Reporter: mats, Assigned: dmajor)

References

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

[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*)
...
Given the stack and regression range, perhaps it's bug 1165410?
Flags: needinfo?(terrence)
Summary: crash in dosprintf → Startup crash in dosprintf
Seems likely. All current instances appear to be on windows, with memchaser installed. I've been testing in that configuration all morning without success.
Flags: needinfo?(terrence)
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.
Assignee: nobody → dmajor
Blocks: 1165410
Yup, just saw the same thing when looking at dosprintf.
Attachment #8613623 - Flags: review?(terrence)
Comment on attachment 8613623 [details] [diff] [review]
Fix format specifiers

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

\o/ Thanks!
Attachment #8613623 - Flags: review?(terrence) → review+
https://hg.mozilla.org/mozilla-central/rev/eced3077126b
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Adding a tracking flag for FF41. Also requesting QE team to verify the fix if this is easy to reproduce.
Flags: qe-verify+
Flags: needinfo?(kairo)
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!
(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.
Status: RESOLVED → VERIFIED
Flags: needinfo?(kairo)
You need to log in before you can comment on or make changes to this bug.