On 2010-12-16 19:21 PDT, Marsh Ray wrote:
On 12/16/2010 04:39 PM, Matej Kurpel wrote:
ChildEBP RetAddr Args to Child
0015f130 5fa0c52b e06d7363 00000001 00000003
KERNELBASE!RaiseException+0x58 (FPO: [Non-Fpo])
0015f168 5fa14f13 0015f178 5fa7aa24 5fa5c11c
MOZCRT19!_CxxThrowException+0x46 (FPO: [Non-Fpo]) (CONV: stdcall)
[f:\sp\vctools\crt_bld\self_x86\crt\prebuild\eh\throw.cpp @ 161]
So Mozilla builds its own CRT without FPO, cool.
Yes, Mozilla builds its own CRT, which is a modified version of the MSVC
CRT, whose sources come only with the pay (not free) versions of MSVC.
They do this in order to replace MSVC's normal heap code (malloc) with
their own "JEmalloc".
Mozilla's source repository doesn't include ANY of the MSVC source code,
but only includes a ed script that patches that source without including
any of it. Sadly, this means that people with the free MSVC cannot build
MOZCRT19, because they lack the sources to be patched. IMO, this is a
flaw for an open source project, but ... :(
0015f180 003b474b 00000028 0015f290 5f9ad1d9 MOZCRT19!operator new+0x73
(FPO: [1,3,0]) (CONV: cdecl)
The above func must be statically linked from the Mic CRT into the Moz
CRT. So it's still FPO. Weird.
Right. IIRC, it's built from the plain old MSVC new.cpp source.
It calls malloc and throws an exception if malloc returns NULL.
[e:\buildbot\win32_build_31\build\objdir-tb\mozilla\memory\jemalloc\crtsrc\new....@61]
Looking at
http://mxr.mozilla.org/mozilla-central/source/memory/jemalloc/ I don't
see the source or crtsrc\new.cpp. Must be copied in from Microsoft
source code a build time.
Right.
In any case, 'operator new' is throwing a C++ exception. Ordinarily that
would be due to a bad parameter (e.g., -1) or lack of memory.
Right. Any NULL return from malloc causes this.
In this case is it maybe asking for 0x00000028 = 40 bytes?
I wouldn't bet much money that JEmalloc never modifies its input
arguments. That's always allowed in c (as you know) which always passes
arguments by value.
0015f198 003b47db 09385800 00000000 003d3b55
thunderbird!nsDOMEvent::nsDOMEvent+0x63 (FPO: [Non-Fpo]) (CONV: thiscall)
[e:\buildbot\win32_build_31\build\mozilla\content\events\src\nsdomevent....@136]
http://mxr.mozilla.org/mozilla-central/source/content/events/src/nsDOMEvent.cpp
Line 132 is in the middle of a comment, so clearly I'm n ot looking at
the right source. Below it is a 'new nsEvent'.
The sources from which Thunderbird are built come from Mozilla's
"comm-central" repository. I think that line 136 could be either a
reference to the line on which the "new" call itself occurs, or the
following line.
The versions of the nsdomevent source in which the new call occurs on line
135 are dated 2009-04-02 14:34 -0500 ... 2009-06-30 10:56 +0300
and line 136 from 2009-09-11 16:13 -0700 ... 2009-11-30 13:31 -0500
all of which are over a year old now.
See
http://hg.mozilla.org/mozilla-central/log/90b17476216d/content/events/src/nsDOMEvent.cpp
and
http://hg.mozilla.org/mozilla-central/log/d9267e3d8f8c/content/events/src/nsDOMEvent.cpp
and
http://hg.mozilla.org/mozilla-central/annotate/9e7a2c507c41/content/events/src/nsDOMEvent.cpp#l136
But 'nsEvent' looks like it would take more than 40 bytes.
yes.
So, skipping down a bit, it looks like something has already gone wrong
before this exception is thrown. The app is attempting to show an alert
box, which fails because of an out-of-memory condition.
Agreed. further back on the stack, we see:
nsMsgSendReport::DisplayReport+0x28c nsmsgsendreport....@428]
nsMsgComposeAndSend::Fail+0x73 nsmsgsend....@3812]
nsMsgComposeAndSend::GatherMimeAttachments+0x113d nsmsgsend....@1147]
That suggests that the attempt to generate and attach all the attachments
failed, and I'd guess that is likely due to Matej's intentional
introduction of a failure into C_SignInit.
So, C_SignInit failed, and then the attempt to report that failure in an
alert pop-up dialog fails due to heap allocation failure, perhaps due to
heap exhaustion, or heap corruption.
The details are probably not important.
Well, I think the big question is: why does the heap allocation fail?
You need to track down where the first error occurs.
My first wild guess is that Matej's PKCS#11 module is doing something bad
to the heap. My second one is that NSS or PSM is trying to free to the
MOZCRT17 heap something that was allocated from another heap.
