Closed Bug 464413 Opened 13 years ago Closed 13 years ago

"Assertion failed: _stats.freePages == _stats.pages"

Categories

(Core :: JavaScript Engine, defect, P2)

x86
macOS
defect

Tracking

()

VERIFIED FIXED
mozilla1.9.1b2

People

(Reporter: jruderman, Assigned: gal)

References

Details

(4 keywords)

Attachments

(2 files)

Attached file testcase
During js_FinishJIT, this testcase triggers:

Assertion failed: _stats.freePages == _stats.pages
(../nanojit/Fragmento.cpp:99)

This is a regression from bug 464138.  I initially reported it in the wrong place: bug 456511 comment 37.  jsfunfuzz hits this bug every time I run it.
Assignee: general → gal
Status: NEW → ASSIGNED
Attachment #347727 - Flags: review?(brendan)
Attachment #347727 - Flags: review?(brendan) → review+
Comment on attachment 347727 [details] [diff] [review]
Don't lose the lirbuf if we already allocated one.

Thanks,

/be
Flags: blocking1.9.1?
http://hg.mozilla.org/tracemonkey/rev/038d7a5a32d8
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment on attachment 347727 [details] [diff] [review]
Don't lose the lirbuf if we already allocated one.

This fixes the leak on mc. The patch is green on the TM build/test infrastructure.
Attachment #347727 - Flags: approval1.9.1b2?
Not a security bug, but a serious leak (every String.replace leaks 4k memory).
Priority: -- → P2
Target Milestone: --- → mozilla1.9.1b2
Actually slight correction. We leak 40 bytes or so for the lirbuf descriptor. The 4k will be reclaimed when the code cache resets.
Flags: blocking1.9.1? → blocking1.9.1+
Comment on attachment 347727 [details] [diff] [review]
Don't lose the lirbuf if we already allocated one.

(now blocking, doesn't need explicit approval)
Attachment #347727 - Flags: approval1.9.1b2?
Would it cause hassle for tm developers if bugs were not marked fixed until they land on m-c?

Or do we need a fixed-mozilla-central or similar keyword?
We are not closing externally reported bugs. We are currently closing bugs that were filed against the TM tree as we fix them there. If thats still troublesome, we can further relax the rules. The main problem is that bugs have to be closed once we merge, which we keep forgetting. Feel free to open this bug again for tracking purposes if you want.
I've been closing tm-only bugs. That is, bugs that I know are not in m-c. Otherwise it's too likely I'll hide a bug from an m-c-based tester who is trying to avoid filing a dup.

/be
this assertion was covered by 10 different tests.
Flags: in-testsuite+
Flags: in-litmus-
11.

ecma_2/String/match-001.js
ecma_3/String/15.5.4.11.js
ecma_3/String/regress-189898.js
ecma_3/String/regress-83293.js
js1_5/Regress/regress-167658.js
js1_5/Regress/regress-179524.js
js1_6/extensions/regress-312385-01.js
js1_8_1/trace/trace-test.js
js1_8/genexps/regress-380237-01.js
js1_8/regress/regress-384412.js
v 1.9.1, 1.9.2
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.