[FIX]Crash when dragging non-mozilla IDataObject collections over mozilla

VERIFIED FIXED in mozilla1.0.1

Status

()

Core
XUL
P5
critical
VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: Neil Fraser, Assigned: rods (gone))

Tracking

({crash})

Trunk
mozilla1.0.1
x86
Windows 98
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ADT2 RTM] [ETA 06/21])

Attachments

(3 attachments)

204.02 KB, application/octet-stream
Details
10.34 KB, text/plain
Details
5.72 KB, patch
Mike Pinkerton (not reading bugmail)
: review+
dbaron
: approval+
Details | Diff | Splinter Review
(Reporter)

Description

17 years ago
1) Open an Outlook Express email containing an attachment.
2) Open Mozilla.
3) Drag the attachment from Outlook Express, across Mozilla's window, then drop
on the desktop.
4) Watch Mozilla crash.

Tested this on two Windows 98 computers.  100% repeatable.  Doesn't matter what
the attachment is (Jpeg, Word document, RTF).

[I know, I shouldn't be using Outlook.]
wfm with win2k build 20011023..

Reporter: 
Please add the build ID in every bug report !
Can you please use a talkback enabled build and after talkback submitted the
crash, run <Install-dir>\bin\components\talkback.exe and poste the talkback ID here.

Thanks
 Matthias
(Reporter)

Comment 2

17 years ago
My apologies.

Build ID: 2001101117
Incident ID: TB37057510H
more work for Stephen :-)
Incident ID 37057510
Stack Signature js_AllocStack ca19e053
Bug ID
Trigger Time 2001-10-23 02:25:37
Email Address neil@digitalroutes.co.uk
URL visited www.cnn.com
User Comments Dragged a .doc file from an attachment in Outlook Express, across
Mozilla, and onto the desktop. Mozilla shouldn't have been involved. But Mozilla
crashed as a result of this drag-over. Second time I've seen this happen.
Build ID 2001101120
Product ID MozillaBranch
Platform ID Win32
Trigger Reason Access violation
Stack Trace
js_AllocStack [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 398]
nsXPCWrappedJSClass::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp, line 914]
nsXPCWrappedJS::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp, line 430]
PrepareAndDispatch
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 117]
SharedStub
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 139]
nsEventListenerManager::HandleEventSubType
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1214]
nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1733]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3719]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3700]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3700]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3700]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3700]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3I700]
nsXULElement::HandleChromeEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 5113]
GlobalWindowImpl::HandleDOMEvent
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 620]
nsDocument::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 3024]
nsEventStateManager::PreHandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 462]
PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5712]
PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5642]
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 392]
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 365]
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 365]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2094]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 83]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 749]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 766]
nsWindow::DispatchFocus
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4504]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3385]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1014]
KERNEL32.DLL + 0x363b (0xbff7363b)
KERNEL32.DLL + 0x24407 (0xbff94407) 
marking NEW based on the stack
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash

Comment 6

17 years ago
-> looks like drag/drop js is puking.?
Assignee: joki → pinkerton
the only thing i can think of is some object is not correctly refcounted.
Target Milestone: --- → mozilla1.0

Comment 8

17 years ago
nsbeta1+ because it is a crash
Keywords: nsbeta1+
the bulk of the dnd code has been rewritten to not go through JS. can i get a
new stack trace from a build later than 2/25/02?
Neil, do you still see this? I just tried with build 2002-02-26-03 on Windows
2000 and didn't crash.
(Reporter)

Comment 11

17 years ago
I agree, this specific bug seems to have gone away.  But in its place there is a
very similar bug:

Drag any attachment from Outlook and drop it on Mozilla.
Nothing will happen.
Change the focus away from Mozilla, and watch Mozilla crash.

Build ID: 2002022703
Incident ID: TB3476587Q

Should I open a new bug, or let this one morph slightly?
That's up to Pinkerton - here's the new, albeit brief, stack:

Stack Signature  0x24748b56 76d24265
Trigger Time 2002-02-28 08:56:49
Email Address neil@digitalroutes.co.uk
URL visited http://tayleurmayde.com/japanese/
Build ID 2002022709
Product ID MozillaTrunk
Platform
Operating System Win32
Module
Trigger Reason Access violation
User Comments Dragging a jpg from an Outlook email attachment onto Mozilla has
no effect, then causes a crash about 15 seconds later.
Stack Trace
0x24748b56 
ohhhhhhhhh 0x24748b56! no wonder!

give me something more here, folks ;)
Priority: -- → P5
(Reporter)

Comment 14

16 years ago
Here's another traceback.  Lets hope this one is a bit longer.  :-)

Build: 2002032603
ID: TB4598988W

Updated

16 years ago
Whiteboard: [ADT2]

Updated

16 years ago
QA Contact: madhur → rakeshmishra

Comment 15

16 years ago
I can reproduce this easily.  I get this stack in the debugger:

NTDLL! 77f7f570()
js_GC(JSContext * 0x031e8d40, unsigned int 0) line 1176 + 41 bytes
js_ForceGC(JSContext * 0x031e8d40, unsigned int 0) line 979 + 13 bytes
JS_GC(JSContext * 0x031e8d40) line 1644 + 11 bytes
nsJSContext::Notify(nsJSContext * const 0x031e8b60, nsITimer * 0x031a1eb0) line
1569 + 13 bytes
nsTimerImpl::Fire() line 348
nsTimerManager::FireNextIdleTimer(nsTimerManager * const 0x012cd558) line 591
nsAppShell::Run(nsAppShell * const 0x00c89b70) line 134
nsAppShellService::Run(nsAppShellService * const 0x01280068) line 451
main1(int 1, char * * 0x004448a0, nsISupports * 0x00000000) line 1431 + 32 bytes
main(int 1, char * * 0x004448a0) line 1779 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e7eb69()

Comment 16

16 years ago
Or

NTDLL! 77f7f570()
js_AllocGCThing(JSContext * 0x014394c8, unsigned int 0) line 465 + 41 bytes
js_NewObject(JSContext * 0x014394c8, JSClass * 0x01404ef4, JSObject *
0x03043b78, JSObject * 0x00c34f88) line 1611 + 11 bytes
JS_NewObject(JSContext * 0x014394c8, JSClass * 0x01404ef4, JSObject *
0x03043b78, JSObject * 0x00c34f88) line 2003 + 21 bytes
XPCWrappedNative::Init(XPCCallContext & {...}, JSObject * 0x00c34f88, const
XPCNativeScriptableCreateInfo * 0x00126a1c) line 703 + 27 bytes
XPCWrappedNative::GetNewOrUsed(XPCCallContext & {...}, nsISupports * 0x02a94a10,
XPCWrappedNativeScope * 0x0145a338, XPCNativeInterface * 0x030b7ba8,
XPCWrappedNative * * 0x00126a60) line 351 + 27 bytes
XPCConvert::NativeInterface2JSObject(XPCCallContext & {...},
nsIXPConnectJSObjectHolder * * 0x00126b00, nsISupports * 0x02a94a10, const nsID
* 0x00127070, JSObject * 0x02ba4b08, unsigned int * 0x00000000) line 1059 + 30 bytes
XPCConvert::NativeData2JS(XPCCallContext & {...}, long * 0x00126f74, const void
* 0x00127120, const nsXPTType & {...}, const nsID * 0x00127070, JSObject *
0x02ba4b08, unsigned int * 0x00000000) line 461 + 58 bytes
nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJSClass * const 0x02bea0a0,
nsXPCWrappedJS * 0x033080a8, unsigned short 3, const nsXPTMethodInfo *
0x012b4220, nsXPTCMiniVariant * 0x00127120) line 1084 + 46 bytes
nsXPCWrappedJS::CallMethod(nsXPCWrappedJS * const 0x033080a8, unsigned short 3,
const nsXPTMethodInfo * 0x012b4220, nsXPTCMiniVariant * 0x00127120) line 430
PrepareAndDispatch(nsXPTCStubBase * 0x033080a8, unsigned int 3, unsigned int *
0x001271d0, unsigned int * 0x001271c0) line 115 + 31 bytes
SharedStub() line 139
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x03308198,
nsIDOMEvent * 0x02a94a10, nsIDOMEventTarget * 0x02c06b48, unsigned int 1,
unsigned int 4) line 1219 + 20 bytes
nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x02c06bb8,
nsIPresContext * 0x0322c598, nsEvent * 0x00129334, nsIDOMEvent * * 0x00128e10,
nsIDOMEventTarget * 0x02c06b48, unsigned int 4, nsEventStatus * 0x00129330) line
1736 + 36 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x02c06b40, nsIPresContext *
0x0322c598, nsEvent * 0x00129334, nsIDOMEvent * * 0x00128e10, unsigned int 4,
nsEventStatus * 0x00129330) line 3461
nsXULElement::HandleDOMEvent(nsXULElement * const 0x02c06dc0, nsIPresContext *
0x0322c598, nsEvent * 0x00129334, nsIDOMEvent * * 0x00128e10, unsigned int 4,
nsEventStatus * 0x00129330) line 3442
nsXULElement::HandleDOMEvent(nsXULElement * const 0x02c06ee8, nsIPresContext *
0x0322c598, nsEvent * 0x00129334, nsIDOMEvent * * 0x00128e10, unsigned int 4,
nsEventStatus * 0x00129330) line 3442
nsXULElement::HandleDOMEvent(nsXULElement * const 0x030b1840, nsIPresContext *
0x0322c598, nsEvent * 0x00129334, nsIDOMEvent * * 0x00128e10, unsigned int 4,
nsEventStatus * 0x00129330) line 3442
nsXULElement::HandleDOMEvent(nsXULElement * const 0x030ddbf8, nsIPresContext *
0x0322c598, nsEvent * 0x00129334, nsIDOMEvent * * 0x00128e10, unsigned int 4,
nsEventStatus * 0x00129330) line 3442
nsXULElement::HandleDOMEvent(nsXULElement * const 0x030de3a8, nsIPresContext *
0x0322c598, nsEvent * 0x00129334, nsIDOMEvent * * 0x00128e10, unsigned int 4,
nsEventStatus * 0x00129330) line 3442
nsXULElement::HandleChromeEvent(nsXULElement * const 0x030de3b8, nsIPresContext
* 0x0322c598, nsEvent * 0x00129334, nsIDOMEvent * * 0x00128e10, unsigned int 4,
nsEventStatus * 0x00129330) line 4689 + 36 bytes
GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x031e8a30,
nsIPresContext * 0x0322c598, nsEvent * 0x00129334, nsIDOMEvent * * 0x00128e10,
unsigned int 4, nsEventStatus * 0x00129330) line 751
nsDocument::HandleDOMEvent(nsDocument * const 0x03462038, nsIPresContext *
0x0322c598, nsEvent * 0x00129334, nsIDOMEvent * * 0x00128e10, unsigned int 1,
nsEventStatus * 0x00129330) line 3409
nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x0347c1c0,
nsIPresContext * 0x0322c598, nsEvent * 0x00129648, nsIFrame * 0x0347eaac,
nsEventStatus * 0x00129494, nsIView * 0x0322b298) line 490
PresShell::HandleEventInternal(nsEvent * 0x00129648, nsIView * 0x0322b298,
unsigned int 1, nsEventStatus * 0x00129494) line 5986 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x0346ac74, nsIView * 0x0322b298,
nsGUIEvent * 0x00129648, nsEventStatus * 0x00129494, int 1, int & 1) line 5915 +
25 bytes
nsViewManager::HandleEvent(nsView * 0x0322b298, nsGUIEvent * 0x00129648, int 0)
line 2030
nsView::HandleEvent(nsViewManager * 0x0322d690, nsGUIEvent * 0x00129648, int 0)
line 306
nsViewManager::DispatchEvent(nsViewManager * const 0x0322d690, nsGUIEvent *
0x00129648, nsEventStatus * 0x001295b8) line 1881 + 23 bytes
HandleEvent(nsGUIEvent * 0x00129648) line 83
nsWindow::DispatchEvent(nsWindow * const 0x031abbdc, nsGUIEvent * 0x00129648,
nsEventStatus & nsEventStatus_eIgnore) line 865 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x00129648) line 886
nsWindow::DispatchFocus(unsigned int 105, int 1) line 4907 + 15 bytes
nsWindow::ProcessMessage(unsigned int 7, unsigned int 19333458, long 0, long *
0x00129a1c) line 3733 + 23 bytes
nsWindow::WindowProc(HWND__ * 0x00460240, unsigned int 7, unsigned int 19333458,
long 0) line 1130 + 27 bytes
USER32! 77d43a5f()
USER32! 77d43b2e()
USER32! 77d45874()
USER32! 77d458a4()
NTDLL! 77f5108f()
GlobalWindowImpl::Focus(GlobalWindowImpl * const 0x031e8a34) line 2371 + 25 bytes
nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x02cd2ea8,
nsIPresContext * 0x02a86ac0, nsEvent * 0x0012a41c, nsIFrame * 0x03095120,
nsEventStatus * 0x0012a268, nsIView * 0x014633c8) line 640
PresShell::HandleEventInternal(nsEvent * 0x0012a41c, nsIView * 0x014633c8,
unsigned int 1, nsEventStatus * 0x0012a268) line 5986 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x01463b34, nsIView * 0x014633c8,
nsGUIEvent * 0x0012a41c, nsEventStatus * 0x0012a268, int 1, int & 1) line 5915 +
25 bytes
nsViewManager::HandleEvent(nsView * 0x014633c8, nsGUIEvent * 0x0012a41c, int 0)
line 2030
nsView::HandleEvent(nsViewManager * 0x02a87410, nsGUIEvent * 0x0012a41c, int 0)
line 306
nsViewManager::DispatchEvent(nsViewManager * const 0x02a87410, nsGUIEvent *
0x0012a41c, nsEventStatus * 0x0012a38c) line 1881 + 23 bytes
HandleEvent(nsGUIEvent * 0x0012a41c) line 83
nsWindow::DispatchEvent(nsWindow * const 0x01463474, nsGUIEvent * 0x0012a41c,
nsEventStatus & nsEventStatus_eIgnore) line 865 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012a41c) line 886
nsWindow::DispatchFocus(unsigned int 107, int 1) line 4907 + 15 bytes
nsWindow::ProcessMessage(unsigned int 7, unsigned int 37617840, long 0, long *
0x0012a7f0) line 3736 + 23 bytes
nsWindow::WindowProc(HWND__ * 0x01270152, unsigned int 7, unsigned int 37617840,
long 0) line 1130 + 27 bytes
USER32! 77d43a5f()
USER32! 77d43b2e()
USER32! 77d45874()
USER32! 77d458a4()
NTDLL! 77f5108f()
GlobalWindowImpl::Focus(GlobalWindowImpl * const 0x02ac010c) line 2371 + 25 bytes
nsWebShellWindow::HandleEvent(nsGUIEvent * 0x0012ab44) line 592
nsWindow::DispatchEvent(nsWindow * const 0x02a9a0bc, nsGUIEvent * 0x0012ab44,
nsEventStatus & nsEventStatus_eIgnore) line 865 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012ab44) line 886
nsWindow::DispatchFocus(unsigned int 105, int 1) line 4907 + 15 bytes
nsWindow::ProcessMessage(unsigned int 7, unsigned int 0, long 0, long *
0x0012af18) line 3733 + 23 bytes
nsWindow::WindowProc(HWND__ * 0x023e00b0, unsigned int 7, unsigned int 0, long
0) line 1130 + 27 bytes
USER32! 77d43a5f()
USER32! 77d43b2e()
USER32! 77d45874()
USER32! 77d458a4()
NTDLL! 77f5108f()
USER32! 77d46ffb()
nsWindow::DefaultWindowProc(HWND__ * 0x023e00b0, unsigned int 6, unsigned int 1,
long 0) line 1157
USER32! 77d43a5f()
USER32! 77d43b2e()
USER32! 77d47419()
USER32! 77d5ba3f()
nsWindow::WindowProc(HWND__ * 0x023e00b0, unsigned int 6, unsigned int 1, long
0) line 1137 + 31 bytes
USER32! 77d43a5f()
USER32! 77d43b2e()
USER32! 77d45874()
USER32! 77d458a4()
NTDLL! 77f5108f()
USER32! 77d4f58c()
USER32! 77d6aaae()
ok, so it's crashing in xpconnect. any ideas why and what object we're trying to
manipulate here? cc'ing jband, he might be able to give some pointers.

Comment 18

16 years ago
pinkerton: actually, it is crashing in the JS engine :)

I thought about this for a while, but have not installed OE and attempted to
reproduce the assert/crash. blaker: thanks for the stacks. The thing missing is
information on what is going on on the other threads when this crashes.

Here is what I think is going on...

At js_AllocGCThing line 465 is an assertion that gc is not running.
At js_GC line 1176 is an assertion that would only botch if code is running then
it shouldn't be.

Given how the gc and the JS request model work, and the fact that we force gc to
only happen on the main thread, and the fact that xpconnect will always enter a
request before calling into js *except on a main thread only JSContext*, I would
say that the problem is that the OLE d'n'd event that is coming in and being
processed as a window event is coming in on some other thread than the main
thread. But, the event comes in associated with a window and the DOM code pushes
that window's JSContext on the thread context stack. This is a JSContext that
should only be used on the main thread. But, I believe it is being used on a
non-main thread. So, when the call goes into xpconnect using that JSContext,
xpconnect does not try to enter into a request (which it can't legally do
because the context has no explicit thread affinity - JS_GetContextThread
returns null) and we end up breaking the JS rules by sneaking through the door
and running in JS on another thread while the main thread happens to be doing a
GC. This hits the fatal asserts and/or crashes.

Assuming I'm right, the DOM event stuff ought to detect *early* that an event
that comes in is not happening on the main thread. I'm not certain what it
should do exactly when it detects this case, but it should certainly not process
the event as if it were on the main thread.

Comments and ideas?
getting off my plate --> jband
Assignee: pinkerton → jband

Comment 20

16 years ago
I'm not accepting mozilla bugs at this point. I don't think this is an xpconnect
bug, but I'm going to throw it at dbradley anyway. Please diagnose further or
just pass it along if you can think of who'll dig it out.
Assignee: jband → dbradley

Comment 21

16 years ago
Created attachment 85599 [details]
Zip of Purify log of drag&drop

It appears there's something screwy in the drag and drop code, and possibly the
clipboard handling code for Windows.

The first thing that crops up is that mDataObjects in nsDataObjCollection is
null or maybe uninitialized in release builds. Apparently something is catching
that exception and the code continues.

Purify reports one error before the null mDataObjects is access. I've seen the
LookupAccountNameW error before when pasting text into the browser. Allocation
and assignment happens within the call to nsDragService::IsCollectionObject
call to QueryGetData. So when I first saw it, I assumed it was a bug on the
source app, that could still be the case, but I don't know enough about
Window's clipboard logic to know for sure.

The next item is more to the heart as well as the subsequent items. Below is a
small snippet of the error contained in the Purify log I'm attaching.

    Reading 4 bytes from 0x0821094c (4 bytes at 0x0821094c illegal)
    Address 0x0821094c is 13 bytes past the end of a 24 byte block at
0x08210928
    Address 0x0821094c points to a HeapAlloc'd block in the default heap
    Thread ID: 0x6c4
    Error location
	nsDragService::GetNumDropItems(UINT *) [nsDragService.cpp:177]
	      if ( IsCollectionObject(mDataObject) ) {
		nsDataObjCollection * dataObjCol =
NS_STATIC_CAST(nsDataObjCollection*, mDataObject);
		if ( dataObjCol )
	 =>	  *aNumItems = dataObjCol->GetNumDataObjects();
	      }
	      else {
		// Next check if we have a file drop. Return the number of
files in

Comment 22

16 years ago
Reassigning to Widgets. Hopefully I got the right component.
Assignee: dbradley → rods
Component: Event Handling → XP Toolkit/Widgets
(Assignee)

Updated

16 years ago
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 23

16 years ago
Works for me (mozilla 1.0 rc3, outlook express 5.5, win2k, dragging a
PNG image out of an OE mail message, across Mozilla, to the desktop).

I've filed a separate bug (bug 148864) about the problem of dragging
an attachment from Outlook Express directly into Mozilla's window.

Comment 24

16 years ago
I still get a crash when I move over mail as well. You just have to do a lot of
moving. It doesn't usually happen if I just drag over and drop onto another
window. It will happen almost always if I drag over the button bar near the top
of the browser.

Both cases seem to stem from the same problems. They both have buffer overruns
in LookupAccountNameW and both have second errors with calls to
GetNumDataObjects. So I don't think we really need two bugs for this.

For the LookupAccountNameW error, this appears to be a case where there's a
mismatch between the type of buffer Unicode vs ANSI. In this case, a buffer to
receive the domain name. I've seen one other report on another application that
has the same problem. I couldn't find anything in MSDN or elsewhere, though.
This buffer is allocated within the COM call and then overwritten in this same
call, this may very well be outside of our control.

Comment 25

16 years ago
Created attachment 86227 [details]
Text version of the Purify log

Contains the first two errors reported in text form
IIRC someone (jband?) already tracked down an ABW in the OLE code to being
simply a bug in the OLE code and not something we can do anything about. I'm not
sure however if the OS and other circumstances around that other error were the
same as here tho...

Comment 27

16 years ago
Thanks, I looked everywhere but bugzilla about the error.

In any case, for this bug, the second error is the one to focus on and I think
my comment about mDataObjects being null in comment 21 is the key. Apparently
this code gets executed in an exception handlers, because I jump out as soon as
I hit the instruction to get the count.
(Assignee)

Comment 28

16 years ago
Pleas ehlpe out, what is the second error? and how do I easily reproduce it?

Comment 29

16 years ago
I was refering to the second purify error. To reproduce simply drag an
attachment from OutlookExpress over the toolbar on the browser. You may not
immediately crash. There's an exception handlers somewhere that catches it. If
you run in the VC++ debugger go to Debug|Exceptions and change Access Violation
to Stop Always.

I think the heart of the matter is this cast:

nsDataObjCollection* dataObjCol = NS_STATIC_CAST(nsDataObjCollection*, mDataObject);

This code seems to assume that all data objects coming through here with a
MULTI_MIME format was created by Mozilla. In this case it wasn't, thus the
nsDataObjCollection specific datamembers are dangling off the edge of the
initialized object.

I think nsDragService::IsCollectionObject needs to be smarter or
nsDataObjCollection needs to be retooled to handle this situation.
(Assignee)

Comment 30

16 years ago
Created attachment 87508 [details] [diff] [review]
patch

Add an interface to nsDataObjectCollection so we can QI to check to make sure
it is one of our objects before doing the static cast.

testcase in bug no longer crashes and I am still able to D&D mulitple items
(collections) within mozilla.
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Comment on attachment 87508 [details] [diff] [review]
patch

r=pink. good catch to everyone involved.
Attachment #87508 - Flags: review+

Comment 32

16 years ago
The patch quiets Purify
(Assignee)

Comment 33

16 years ago
Changing Summary - For the record, this really isn't just an Outlook problem, it
could happen when multiple objects from any other application is dragged across
Mozilla.
Summary: Dragging attachment from Outlook to desktop crashes Mozilla → Crash when dragging non-mozilla IDataObject collections over mozilla
(Assignee)

Updated

16 years ago
Summary: Crash when dragging non-mozilla IDataObject collections over mozilla → [FIX]Crash when dragging non-mozilla IDataObject collections over mozilla
Comment on attachment 87508 [details] [diff] [review]
patch

sr=jst if you clean up the messed up indentation in nsDataObjCollection.cpp
Attachment #87508 - Flags: superreview+
(Assignee)

Comment 35

16 years ago
fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
(Assignee)

Updated

16 years ago
Keywords: adt1.0.1

Comment 36

16 years ago
rakeshmishra, could you verify this on the trunk?

Updated

16 years ago
Keywords: approval, mozilla1.0.1, verifyme
Whiteboard: [ADT2] → [ADT2 RTM]

Comment 37

16 years ago
Finally I reproduced it on branch.
Then installed today's trunk build and with the same attachments tried to get
crash. Seems fine. Verified on Win2K.
Status: RESOLVED → VERIFIED
Keywords: verifyme

Comment 38

16 years ago
adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch, pending
drivers' approval. pls check this in asap, then add the "fixed1.0.1" keyword.
Keywords: adt1.0.1 → adt1.0.1+
Whiteboard: [ADT2 RTM] → [ADT2 RTM] [ETA 06/21]
Comment on attachment 87508 [details] [diff] [review]
patch

Please land this on the 1.0.1 branch.  Once there, replace the
"mozilla1.0.1+" keyword with the "fixed1.0.1" keyword.
Attachment #87508 - Flags: approval+
Keywords: mozilla1.0.1 → mozilla1.0.1+
(Assignee)

Comment 40

16 years ago
fixed on branch
Keywords: mozilla1.0.1+ → fixed1.0.1
You need to log in before you can comment on or make changes to this bug.