Closed
Bug 529849
Opened 15 years ago
Closed 14 years ago
Assertion failed: _allocator.free & rmask(r) (../../../js/src/nanojit/Assembler.cpp:433)
Categories
(Core Graveyard :: Nanojit, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: ginnchen+exoracle, Assigned: leon.sha)
Details
(Whiteboard: fixed-in-nanojit, fixed-in-tracemonkey, fixed-in-tamarin)
Attachments
(2 files)
1.36 KB,
patch
|
gal
:
review+
|
Details | Diff | Splinter Review |
2.35 KB,
patch
|
n.nethercote
:
review-
|
Details | Diff | Splinter Review |
Run 'make check' in obj/js/src of debug version.
This bug happened because Assembler::argRegs[] and Assembler::savedRegs[] have same registers. Assembler::savedRegs[] is not needed for sparc because the registers are already saved automatically by "save" instruction. But since NumSavedRegs can not be zero, I just add a saved reg L1 in this array.
Attachment #413979 -
Flags: review?(gal)
Comment 2•15 years ago
|
||
Comment on attachment 413979 [details] [diff] [review] patch Leon, nanojit lives its own tree now. See https://developer.mozilla.org/en/NanojitMerge Make sure to follow the instructions there when committing.
Attachment #413979 -
Flags: review?(gal) → review+
Updated•15 years ago
|
Component: JavaScript Engine → Nanojit
Priority: -- → P2
QA Contact: general → nanojit
Comment 3•15 years ago
|
||
(In reply to comment #1) > > This bug happened because Assembler::argRegs[] and Assembler::savedRegs[] have > same registers. Assembler::savedRegs[] is not needed for sparc because the > registers are already saved automatically by "save" instruction. But since > NumSavedRegs can not be zero, I just add a saved reg L1 in this array. Why can't NumSavedRegs be zero? A comment explaining the dummy L1 value would be nice.
(In reply to comment #3) > Why can't NumSavedRegs be zero? A comment explaining the dummy L1 value would > be nice. NumSavedRegs is used as the length of savedRegs in LIR.h and Assembler.h. NumSavedRegs to be zero will cause a zero length array. I'll add such a comment when I commit the patch.
Comment 5•15 years ago
|
||
What's wrong with a zero-length array?
Sun Studio C++ doesn't like zero-length array unless you add -features=zla in CXXFLAGS. I think it might be cleaner, if we add -featurs=zla globally, and use 0 for NumSavedRegs. BTW: For the patch, we don't need the line uint32_t kind = ins->paramKind();
Attachment #414224 -
Flags: review?(nnethercote)
Comment 8•15 years ago
|
||
Comment on attachment 414224 [details] [diff] [review] patch zero length array version I know I originally asked what was wrong with zero-length arrays... but apparently they're not legal according to the standard, and MSVC has trouble with them. (The fact that the Sun compiler requires a special flag to accept them also doesn't fill me with confidence.) So I'm rejecting this patch, sorry. Let's just stick to the first patch + an explanatory comment.
Whiteboard: fixed-in-nanojit, fixed-in-tracemonkey → fixed-in-nanojit, fixed-in-tracemonkey, fixed-in-tamarin
http://hg.mozilla.org/projects/nanojit-central/rev/23ed78f42df2 http://hg.mozilla.org/tracemonkey/rev/6c119f0a91f9 http://hg.mozilla.org/tamarin-redux/rev/0b1f6d368985
Status: NEW → ASSIGNED
Updated•15 years ago
|
Attachment #414224 -
Flags: review?(nnethercote) → review-
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•10 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•