If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Crash [@ strcat ] [@ nanojit::LabelMap::dup ] in debug build

RESOLVED WONTFIX

Status

()

Core
JavaScript Engine
--
critical
RESOLVED WONTFIX
9 years ago
6 years ago

People

(Reporter: ted, Unassigned)

Tracking

({crash})

Trunk
x86
Windows XP
crash
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Trying to verify a fix for bug 471635, using Jesse's testcase in bug 471635 comment 0, I was crashing in the JS shell in a Win32 debug build. 
I bisected it down to changeset b369b9f805ba from bug 471821. Looks like "end" in LabelMap::dup is NULL, so we're crashing passing 0x06 to strcpy (end+need).

 	msvcr80d.dll!_strcat()  + 0x89 bytes	
>	js.exe!nanojit::LabelMap::dup(const char * b=0x0013e350)  Line 2281 + 0xd bytes	C++
 	js.exe!nanojit::LirNameMap::formatIns(nanojit::LIns * i=0x00c70004)  Line 1965	C++
 	js.exe!nanojit::VerboseWriter::flush()  Line 571 + 0x1b bytes	C++
 	js.exe!nanojit::VerboseWriter::add_flush(nanojit::LIns * i=0x00c700b0)  Line 563	C++
 	js.exe!nanojit::VerboseWriter::insGuard(nanojit::LOpcode op=LIR_xt, nanojit::LIns * cond=0x00c700ac, nanojit::LIns * x=0x00c700a8)  Line 580	C++
 	js.exe!nanojit::CseFilter::insGuard(nanojit::LOpcode v=LIR_xt, nanojit::LIns * c=0x00c700ac, nanojit::LIns * x=0x00c700a8)  Line 2045 + 0x23 bytes	C++
 	js.exe!nanojit::ExprFilter::insGuard(nanojit::LOpcode v=LIR_xt, nanojit::LIns * c=0x00c700ac, nanojit::LIns * x=0x00c700a8)  Line 994	C++
 	js.exe!nanojit::LirWriter::insGuard(nanojit::LOpcode v=LIR_xt, nanojit::LIns * c=0x00c700ac, nanojit::LIns * x=0x00c700a8)  Line 413	C++
 	js.exe!TraceRecorder::guard(bool expected=false, nanojit::LIns * cond=0x00c700ac, nanojit::LIns * exit=0x00c700a8)  Line 2001	C++
 	js.exe!TraceRecorder::TraceRecorder(JSContext * cx=0x00b83790, VMSideExit * _anchor=0x00000000, nanojit::Fragment * _fragment=0x00b8c2f8, TreeInfo * ti=0x00b8c3c0, unsigned int ngslots=0, unsigned char * globalTypeMap=0x00b6d230, unsigned char * stackTypeMap=0x00b8c430, VMSideExit * innermostNestedGuard=0x00000000, nanojit::Fragment * outerToBlacklist=0x00000000)  Line 1075	C++
 	js.exe!js_StartRecorder(JSContext * cx=0x00b83790, VMSideExit * anchor=0x00000000, nanojit::Fragment * f=0x00b8c2f8, TreeInfo * ti=0x00b8c3c0, unsigned int ngslots=0, unsigned char * globalTypeMap=0x00b6d230, unsigned char * stackTypeMap=0x00b8c430, VMSideExit * expectedInnerExit=0x00000000, nanojit::Fragment * outer=0x00000000)  Line 2747 + 0x47 bytes	C++
 	js.exe!js_RecordTree(JSContext * cx=0x00b83790, JSTraceMonitor * tm=0x00b802c0, nanojit::Fragment * f=0x00b8c2f8, nanojit::Fragment * outer=0x00000000, unsigned int * demotes=0x00000000)  Line 3063 + 0x3d bytes	C++
 	js.exe!js_MonitorLoopEdge(JSContext * cx=0x00b83790, unsigned int & inlineCallCount=1)  Line 3795 + 0x18 bytes	C++
 	js.exe!js_Interpret(JSContext * cx=0x00b83790)  Line 3702 + 0x50e bytes	C++
 	js.exe!js_Execute(JSContext * cx=0x00b83790, JSObject * chain=JSObject [... slots], JSScript * script=JSScript "typein", JSStackFrame * down=0x00000000, unsigned int flags=0, long * result=0x0013fec0)  Line 1564 + 0x9 bytes	C++
 	js.exe!JS_ExecuteScript(JSContext * cx=0x00b83790, JSObject * obj=JSObject [... slots], JSScript * script=JSScript "typein", long * rval=0x0013fec0)  Line 5083 + 0x19 bytes	C++
 	js.exe!Process(JSContext * cx=0x00b83790, JSObject * obj=JSObject [... slots], char * filename=0x00000000, int forceTTY=0)  Line 385 + 0x15 bytes	C++
 	js.exe!ProcessArgs(JSContext * cx=0x00b83790, JSObject * obj=JSObject [... slots], char * * argv=0x00b66c64, int argc=1)  Line 682 + 0x15 bytes	C++
 	js.exe!main(int argc=1, char * * argv=0x00b66c64, char * * envp=0x00b63e40)  Line 4254 + 0x15 bytes	C++
 	js.exe!__tmainCRTStartup()  Line 597 + 0x19 bytes	C
 	js.exe!mainCRTStartup()  Line 414	C
 	kernel32.dll!_BaseProcessStart@4()  + 0x23 bytes
Ted, is this still crashing for you? (I don't have a js shell on Windows.)
I haven't tried it since then.
in a spot check of strcat crashes of past 10 days I found none with nanojit::LabelMap::dup  (but there's only a few dozen crashes, and I didn't check them all)
Severity: normal → critical
Keywords: crash
Crash Signature: [@ strcat ] [@ nanojit::LabelMap::dup ]
Tracer has been removed and doesn't show up on crash stats.
Status: NEW → RESOLVED
Crash Signature: [@ strcat ] [@ nanojit::LabelMap::dup ] → [@ strcat ] [@ nanojit::LabelMap::dup ]
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.