Closed Bug 472385 Opened 11 years ago Closed 10 years ago

TM: Crash in [@fastcopy_I _VEC_memcpy huge_malloc] on QMO site

Categories

(Core :: General, defect, critical)

x86
Windows Vista
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: stephend, Unassigned)

References

()

Details

(Keywords: crash)

Crash Data

Filing in JavaScript Engine, due to "Crashes in jemalloc are usually someone else's fault. Please file the bugs based on the caller instead of in this component."

Steps to Reproduce:

1. Log in to http://quality.mozilla.org/
2. Click on "Doc Page" under the "Create" menu (left-hand side); if you don't have account permissions, let me know and I'll come over and show you the bug
3. In the editor, type "test" and make it an anchor (choose "insert")
4. Type "another test" and make it a link pointing to the above anchor (choose "insert")

After step #4 is usually where I crash, here:

0  	mozcrt19.dll  	fastcopy_I  	
1 	mozcrt19.dll 	_VEC_memcpy 	
2 	mozcrt19.dll 	huge_malloc 	obj-firefox/memory/jemalloc/src/jemalloc.c:4797
3 	js3250.dll 	array_join_sub 	js/src/jsarray.cpp:1395
4 	js3250.dll 	array_join 	js/src/jsarray.cpp:1580
5 	js3250.dll 	js_Interpret 	js/src/jsinterp.cpp:5119
6 	js3250.dll 	js_Invoke 	js/src/jsinterp.cpp:1331
7 	js3250.dll 	js_InternalInvoke 	js/src/jsinterp.cpp:1388
8 	js3250.dll 	JS_CallFunctionValue 	js/src/jsapi.cpp:5244
9 	xul.dll 	nsJSContext::CallEventHandler 	dom/src/base/nsJSEnvironment.cpp:1989
10 	xul.dll 	nsGlobalWindow::RunTimeout 	dom/src/base/nsGlobalWindow.cpp:7678
11 	xul.dll 	nsGlobalWindow::TimerCallback 	dom/src/base/nsGlobalWindow.cpp:8010
12 	xul.dll 	nsTimerImpl::Fire 	xpcom/threads/nsTimerImpl.cpp:420
13 	xul.dll 	nsTimerEvent::Run 	xpcom/threads/nsTimerImpl.cpp:512
14 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:510
15 	xul.dll 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:170
16 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:192
17 	nspr4.dll 	PR_GetEnv 	
18 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:87
19 	firefox.exe 	firefox.exe@0x2197 	
20 	kernel32.dll 	kernel32.dll@0x44910 	
21 	ntdll.dll 	ntdll.dll@0x3e4b5 	
22 	ntdll.dll 	ntdll.dll@0x3e488
Build ID: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090106 Shiretoko/3.1b3pre
Doesn't look like an obvious JIT bug. Any chance of reducing the test case?
(In reply to comment #2)
> Doesn't look like an obvious JIT bug. Any chance of reducing the test case?

Not yet; I can come over and show it to you guys, if you're in S.

I missed a step that helps one reproduce this bug; after creating the document, clicking on "Preview" usually triggers the crash.
I disabled JIT for content, tried this bug 6 times, and was unable to crash with the updated step in comment 3; enabling JIT for content and trying again, I crashed the first time, with the same stack as in comment 0.
Summary: Crash in [@fastcopy_I _VEC_memcpy huge_malloc] on QMO site → TM: Crash in [@fastcopy_I _VEC_memcpy huge_malloc] on QMO site
Flags: blocking1.9.1?
i will try to reproduce the crash and create testcase
This looks like heap corruption leading to the malloc failure. I would suggest running this in a debug build. That might hit an assert closer to the source before the crash happens. If that doesn't turn up anything, enabling malloc debugging mode might help.
I can't seem to reproduce this, at least on debug builds.  Am I doing it right?

0. After clicking "Create," click "Forum Topic."
1. Type "test" into the editor.
2. Click the anchor icon, type test, click insert.
3. Type "another test" into the editor.
4. Highlight, click the link icon, set target to "#test" and click insert.
5. Click preview.
(In reply to comment #7)
> I can't seem to reproduce this, at least on debug builds.  Am I doing it right?
> 
> 0. After clicking "Create," click "Forum Topic."

This should be "Doc Page" (http://quality.mozilla.org/node/add/doc).  Comment 0, #2; you might need permissions to create one, which is what I mentioned to Andreas when I showed it to him in S today.

> 1. Type "test" into the editor.
> 2. Click the anchor icon, type test, click insert.
> 3. Type "another test" into the editor.
> 4. Highlight, click the link icon, set target to "#test" and click insert.
> 5. Click preview.

The rest of the instructions are correct, though.
[1] Just to be pedantic: both sets of STR--comment 7 and comment 8--will work, since they invoke QMO's embedded editor, which is Tiny MCE (http://tinymce.moxiecode.com/).

I suspect that other Tiny MCE demos/installs will trigger this crash too.

[2] Of additional note is that this seems to be a Windows-only crash.
Adding mrbkap. I think he fixed a Tiny MCE-related bug in the tracer before.
There is a similar crash report at bp-bbefe92c-ffec-4b45-adea-a2b792090107:

0  	mozcrt19.dll  	fastcopy_I  	
1 	mozcrt19.dll 	_VEC_memcpy 	
2 	mozcrt19.dll 	huge_malloc 	obj-firefox/memory/jemalloc/src/jemalloc.c:4797
3 	js3250.dll 	array_join_sub 	js/src/jsarray.cpp:1395
4 	js3250.dll 	array_join 	js/src/jsarray.cpp:1580
5 	js3250.dll 	js_Interpret 	js/src/jsinterp.cpp:5119
6 	js3250.dll 	js_Invoke 	js/src/jsinterp.cpp:1331
7 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1606
8 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:563
9 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
10 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
11 	xul.dll 	nsEventListenerManager::HandleEventSubType 	content/events/src/nsEventListenerManager.cpp:1090

Supposedly, this one only happens with Adblock Plus and a particular filter list installed. More information at http://ffextensionguru.wordpress.com/2008/12/24/adblock-pluseasy-listwordpresscrash/
Blocks: abp
Hi, i spent a lot of time today to reproduce this Problem with the steps to reprodcue from comment #7 and comment #8 and so far i'm not able to reproduce this Problem with a 1.9.1 tracemonkey debug/opt build on mac or 1.9.1-tracemonkey opt/debug + 1.9.2 opt/debug build on xp. 

So far because of this i cannot add a testcase or stack
Carsten, do you happen to have a wordpress account? Maybe this can be reproduced with the steps from http://ffextensionguru.wordpress.com/2008/12/24/adblock-pluseasy-listwordpresscrash/? I didn't try because I don't have a wordpress account.
wordpress accounts are free afaik
They are... Anyway, I tried to create a blog at wordpress.com - no crash here with EasyList, neither with Adblock Plus 1.0 nor current development build (using 20090108 Minefield build on Windows XP). But that blog post already suggests that the crash isn't 100% reproducible, it seems to depend on some "random" factors, (clean reinstallation of Adblock Plus "cured" it).
I don't think this can block, and it's almost certainly not a jemalloc bug but some memory corruption, perhaps JIT-related. I think the only way we'd track this down is to catch it in valgrind.
Component: jemalloc → General
Flags: blocking1.9.1? → blocking1.9.1-
QA Contact: jemalloc → general
Stephend, can you still reproduce this crash?  Have you tried on platforms other than Windows, where we might be able to use Valgrind?
(In reply to comment #17)
> Stephend, can you still reproduce this crash?  Have you tried on platforms
> other than Windows, where we might be able to use Valgrind?

No, and no; WFM with Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2b1pre) Gecko/20090922 Namoroka/3.6b1pre (.NET CLR 3.5.30729)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@fastcopy_I _VEC_memcpy huge_malloc]
You need to log in before you can comment on or make changes to this bug.