Bugzilla

Comment 7

•

23 years ago

the only thing i can think of is some object is not correctly refcounted.

Target Milestone: --- → mozilla1.0

saari (gone)

Comment 8

•

23 years ago

nsbeta1+ because it is a crash

Keywords: nsbeta1+

stephend@netscape.com (gone - use stephen.donner@gmail.com instead)

Comment 9

•

23 years ago

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?

Comment 10

•

23 years ago

Neil, do you still see this? I just tried with build 2002-02-26-03 on Windows
2000 and didn't crash.

Neil Fraser

Reporter

Comment 11

•

23 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?

stephend@netscape.com (gone - use stephen.donner@gmail.com instead)

Comment 12

•

23 years ago

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

Comment 13

•

23 years ago

ohhhhhhhhh 0x24748b56! no wonder!

give me something more here, folks ;)

Updated

•

23 years ago

Priority: -- → P5

Neil Fraser

Reporter

Comment 14

•

22 years ago

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

Build: 2002032603
ID: TB4598988W

saari (gone)

Updated

•

22 years ago

Whiteboard: [ADT2]

Rakesh Mishra

Updated

•

22 years ago

QA Contact: madhur → rakeshmishra

Blake Ross

Comment 15

•

22 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()

Blake Ross

Comment 16

•

22 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()

Comment 17

•

22 years ago

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.

John Bandhauer

Comment 18

•

22 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?

Comment 19

•

22 years ago

getting off my plate --> jband

Assignee: pinkerton → jband

John Bandhauer

Comment 20

•

22 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

•

22 years ago

Attached file Zip of Purify log of drag&drop — Details

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

•

22 years ago

Reassigning to Widgets. Hopefully I got the right component.

Assignee: dbradley → rods

Component: Event Handling → XP Toolkit/Widgets

Assignee

Updated

•

22 years ago

Target Milestone: mozilla1.0 → mozilla1.0.1

Damian Yerrick

Comment 23

•

22 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

•

22 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

•

22 years ago

Attached file Text version of the Purify log — Details

Contains the first two errors reported in text form

Johnny Stenback (:jst)

Comment 26

•

22 years ago

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

•

22 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

•

22 years ago

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

Comment 29

•

22 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

•

22 years ago

Attached patch patch — Details — Splinter Review

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

•

22 years ago

Status: NEW → ASSIGNED

Comment 31

•

22 years ago

Comment on attachment 87508 [details] [diff] [review]
patch

r=pink. good catch to everyone involved.

Attachment #87508 - Flags: review+

Comment 32

•

22 years ago

The patch quiets Purify

Assignee

Comment 33

•

22 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

•

22 years ago

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

Johnny Stenback (:jst)

Comment 34

•

22 years ago

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

•

22 years ago

fixed

Status: ASSIGNED → RESOLVED

Closed: 22 years ago

Resolution: --- → FIXED

David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)

Assignee

Updated

•

22 years ago

Keywords: adt1.0.1

scottputterman

Comment 36

•

22 years ago

rakeshmishra, could you verify this on the trunk?

Jaime Rodriguez, Jr.

Updated

•

22 years ago

Keywords: approval, mozilla1.0.1, verifyme

Whiteboard: [ADT2] → [ADT2 RTM]

Olga

Comment 37

•

22 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

Jaime Rodriguez, Jr.

Comment 38

•

22 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 39

•

22 years ago

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+

David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)

Updated

•

22 years ago

Keywords: mozilla1.0.1 → mozilla1.0.1+