Closed Bug 832599 Opened 12 years ago Closed 12 years ago

crash in nsDependentJSString::init @ JS_GetStringCharsZAndLength

Categories

(Core :: DOM: Core & HTML, defect)

21 Branch
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox20 --- unaffected
firefox21 --- unaffected

People

(Reporter: scoobidiver, Unassigned)

References

Details

(Keywords: crash, regression)

Crash Data

With that stack trace, it first showed up in 21.0a1/20130117. The regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d8be4bc4fba8&tochange=712eca11a04e It's likely a regression from bug 824864. Signature JS_GetStringCharsZAndLength(JSContext*, JSString*, unsigned int*) More Reports Search UUID 2eaf8504-4fb0-473d-83e3-625642130119 Date Processed 2013-01-19 10:25:01 Uptime 2438 Last Crash 1.0 days before submission Install Age 11.3 hours since version was first installed. Install Time 2013-01-18 23:08:13 Product Firefox Version 21.0a1 Build ID 20130118030915 Release Channel nightly OS Windows NT OS Version 6.1.7601 Service Pack 1 Build Architecture x86 Build Architecture Info GenuineIntel family 15 model 4 stepping 3 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x2 App Notes AdapterVendorID: 0x1002, AdapterDeviceID: 0x5b64, AdapterSubsysID: 01021002, AdapterDriverVersion: 8.56.1.16 D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers- Processor Notes sp-processor01.phx1.mozilla.com_15787:2008 EMCheckCompatibility True Adapter Vendor ID 0x1002 Adapter Device ID 0x5b64 Total Virtual Memory 2147352576 Available Virtual Memory 1736257536 System Memory Use Percentage 31 Available Page File 3306057728 Available Physical Memory 1475751936 Frame Module Signature Source 0 mozjs.dll JS_GetStringCharsZAndLength js/src/jsapi.cpp:6084 1 xul.dll nsDependentJSString::init dom/base/nsJSUtils.h:105 2 xul.dll nsDependentJSString::init dom/base/nsJSUtils.h:117 3 xul.dll nsJSThunk::EvaluateScript dom/src/jsurl/nsJSProtocolHandler.cpp:351 4 xul.dll nsJSChannel::EvaluateScript dom/src/jsurl/nsJSProtocolHandler.cpp:731 5 xul.dll nsRunnableMethodImpl<void obj-firefox/dist/include/nsThreadUtils.h:367 6 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:627 7 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:82 8 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:208 9 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:182 10 xul.dll nsBaseAppShell::Run widget/xpwidgets/nsBaseAppShell.cpp:163 11 xul.dll nsAppShell::Run widget/windows/nsAppShell.cpp:232 12 xul.dll nsAppStartup::Run toolkit/components/startup/nsAppStartup.cpp:288 13 xul.dll XREMain::XRE_mainRun toolkit/xre/nsAppRunner.cpp:3823 14 xul.dll XREMain::XRE_main toolkit/xre/nsAppRunner.cpp:3890 15 xul.dll XRE_main toolkit/xre/nsAppRunner.cpp:4093 16 firefox.exe do_main browser/app/nsBrowserApp.cpp:195 17 firefox.exe wmain toolkit/xre/nsWindowsWMain.cpp:105 18 firefox.exe __tmainCRTStartup crtexe.c:552 19 kernel32.dll BaseThreadInitThunk 20 ntdll.dll __RtlUserThreadStart 21 ntdll.dll _RtlUserThreadStart More reports at: https://crash-stats.mozilla.com/report/list?signature=JS_GetStringCharsZAndLength%28JSContext*%2C+JSString*%2C+unsigned+int*%29
I think this is a dupe of bug 832435. Patch there will be landing shortly.
Depends on: 832435
Crash Signature: [@ JS_GetStringCharsZAndLength(JSContext*, JSString*, unsigned int*)] → [@ JS_GetStringCharsZAndLength(JSContext*, JSString*, unsigned int*)] [@ JS_GetStringCharsZAndLength(JSContext*, JSString*, unsigned long*)]
OS: Windows 7 → All
Hardware: x86 → All
Crash Signature: [@ JS_GetStringCharsZAndLength(JSContext*, JSString*, unsigned int*)] [@ JS_GetStringCharsZAndLength(JSContext*, JSString*, unsigned long*)] → [@ JS_GetStringCharsZAndLength(JSContext*, JSString*, unsigned int*)] [@ JS_GetStringCharsZAndLength(JSContext*, JSString*, unsigned long*)] [@ JS_GetStringCharsZAndLength(JSContext*, JSString*, unsigned __int64*)]
Bobby: This is still happening in builds as recent as today (1/26), so your other patch doesn't seem to have fixed this. These crashes are all null-derefs, because presumably v isn't a string, so we get NULL when we try to convert it to one. Is JS_WrapValue going to return a string if given a string? I would guess no...
(In reply to Andrew McCreight [:mccr8] from comment #3) > Bobby: This is still happening in builds as recent as today (1/26), so your > other patch doesn't seem to have fixed this. This might have also been bug 833856. Is it still happening even after that landed? > Is JS_WrapValue going to return a string if given a > string? I would guess no... Not sure I grok this.
(In reply to Bobby Holley (:bholley) from comment #4) > This might have also been bug 833856. Is it still happening even after that > landed? There aren't any crashes in 21.0a1/20130128. If it's confirmed, the working range would be: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f18b12139151&tochange=80fed51ae074 The fix of bug 833856 belongs to it.
Depends on: 833856
Okay, maybe it is fine now.
> Not sure I grok this. I meant, maybe the thing it returns is a wrapper, which may not be something tagged as a string? Though I guess it would probably still be a string, so never mind...
(In reply to Andrew McCreight [:mccr8] from comment #7) > > Not sure I grok this. > > I meant, maybe the thing it returns is a wrapper, which may not be something > tagged as a string? Though I guess it would probably still be a string, so > never mind... Yeah IIUC we never get JSObject CCWs that wrap strings.
(In reply to Scoobidiver from comment #5) > There aren't any crashes in 21.0a1/20130128. If it's confirmed It is.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.