Closed Bug 472385 Opened 17 years ago Closed 17 years ago

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

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86
Windows Vista
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: stephend, Unassigned)

References

(
URL
)

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: 17 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.