63563 - copy/paste causes crash

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[K Chayka]

Has happened on every Win32 nightly I've downloaded recently: 12/15, 12/18, 12/21.

Some copy/paste operations cause a crash. Seems to happen regularly when pasting
into a form textarea, such as in this bug report. The number of characters
copied may be a factor, since I have not had a crash when doing a copy/paste
into the URL bar.

Happens pretty consistently when I do the following:
1. Start a new bug report (this form)
2. View Source on a mail message
3. Select the message header section in the View window
4. CTRL-C to copy
5. CTRL-V into the bug Description textarea
6. Crash

The expected results are, of course, that the text is pasted into the textarea.
Dr. Watson report attached.

Comment 1

[K Chayka]

Attachment: dr watson

Comment 2

[Asa Dotzler [:asa]]

122105 win32 talkback stack trace:

   ntdll.dll + 0x4e2e (0x77f64e2e)
     MSVCRT.dll + 0x1436 (0x78001436)
     PR_Free [prmem.c, line 68]
     nsMemoryImpl::Free
[d:\builds\seamonkey\mozilla\xpcom\base\nsMemoryImpl.cpp, line 328]
     nsMemory::Free [d:\builds\seamonkey\mozilla\xpcom\base\nsMemoryImpl.cpp,
line 560]
     nsLinebreakHelpers::ConvertPlatformToDOMLinebreaks
[d:\builds\seamonkey\mozilla\widget\src\xpwidgets\nsPrimitiveHelpers.cpp, line 292]
     nsClipboard::GetDataFromDataObject
[d:\builds\seamonkey\mozilla\widget\src\windows\nsClipboard.cpp, line 637]
     nsClipboard::GetNativeClipboardData
[d:\builds\seamonkey\mozilla\widget\src\windows\nsClipboard.cpp, line 839]
     nsBaseClipboard::GetData
[d:\builds\seamonkey\mozilla\widget\src\xpwidgets\nsBaseClipboard.cpp, line 115]
     nsHTMLEditor::Paste
[d:\builds\seamonkey\mozilla\editor\base\nsHTMLEditor.cpp, line 5750]
     nsHTMLEditorLog::Paste
[d:\builds\seamonkey\mozilla\editor\base\nsHTMLEditorLog.cpp, line 338]
     nsPasteCommand::DoCommand
[d:\builds\seamonkey\mozilla\editor\base\nsEditorCommands.cpp, line 167]
     nsControllerCommandManager::DoCommand
[d:\builds\seamonkey\mozilla\rdf\content\src\nsControllerCommandManager.cpp,
line 190]
     nsEditorController::DoCommand
[d:\builds\seamonkey\mozilla\editor\base\nsEditorController.cpp, line 201]
     nsXBLPrototypeHandler::ExecuteHandler
[d:\builds\seamonkey\mozilla\layout\xbl\src\nsXBLPrototypeHandler.cpp, line 257]
     DoKey [d:\builds\seamonkey\mozilla\layout\xbl\src\nsXBLKeyHandler.cpp, line 93]
     nsXBLKeyHandler::KeyPress
[d:\builds\seamonkey\mozilla\layout\xbl\src\nsXBLKeyHandler.cpp, line 109]
     nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\layout\events\src\nsEventListenerManager.cpp, line
1178]
     nsGenericElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\layout\base\src\nsGenericElement.cpp, line 1408]
     nsHTMLTextAreaElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\layout\html\content\src\nsHTMLTextAreaElement.cpp,
line 574]
     PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 4878]
     PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 4813]
     nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 379]
     nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 352]
     nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 352]
     nsViewManager2::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp, line 1439]
     HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 68]
     nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 691]
     nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 708]
     nsWindow::DispatchKeyEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2321]
     nsWindow::OnUniChar
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2473]
     nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2898]
     nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 944]
     USER32.dll + 0x1820 (0x77e71820)
     0x002f0001

Comment 3

[Asa Dotzler [:asa]]

over to XPCOM

Comment 4

[Fabian Guisset]

Does this happen only when copying from View Source?
I can reproduce too build 2000122320.

Comment 5

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

From the stack trace it looks like the problem is in the windows nsClipboard
code.  However, that hasn't changed in months, so perhaps it's more likely to be
something that code uses.  Changing to XPToolkit/Widgets and cc:ing pinkerton. 
(I doubt that the problem is in nsMemory::Free.)

Comment 6

[David Taylor]

*** Bug 63682 has been marked as a duplicate of this bug. ***

Comment 7

[David Taylor]

added myself to CC list

Comment 8

[K Chayka]

The crash only seems to occur when copying from a View Source window. When
pasted into NotePad, then copied from NotePad and pasted into a form textarea,
no crash occurs. It's all very bizarre. I don't get the same error each time,
either. It could be any one of the following:

Microsoft (R) C Runtime Library attempted to use a null data pointer variable.

Microsoft (R) C Runtime Library attempted to write to memory that does not exist
or is read-only.  It may be using an uninitialized variable, or it may be
attempting to access memory after having freed it.

Win32 Kernel core component attempted to write to memory that does not exist or
is read-only.  It may be using an uninitialized variable, or it may be
attempting to access memory after having freed it.

I made a test page to try to narrow down the character count (or whatever) that
consistently caused it, but was only partially successful. Other weirdness
showed up as I was testing - extra characters/symbols displaying at the end of
some lines of selected text. May or may not be related, but it is odd that this
behavior started occurring when the crashes began. Neither of these occur on the
11-30 build.

Attached Dr Watson of build 122320 crash on MSVCRT, and my test page.

Comment 9

[K Chayka]

Attachment: test page

Comment 10

[K Chayka]

Attachment: dr watson on msvcrt crash

Comment 11

[Peter Trudelle]

->pinkerton

Comment 12

[Mike Pinkerton (not reading bugmail)]

it's not really crashing in the clipboard code, it's crashing in some helpers 
sfraser wrote to convert linebreaks from platform to DOM. something is 
obviously odd about the data we get for the view source window. 

cc'ing sfraser, accepting bug.

Comment 13

[Mike Pinkerton (not reading bugmail)]

this works for me on macos, 1/4/01 debug build. building on win32 now.

Comment 14

[Mike Pinkerton (not reading bugmail)]

the crashers are all in the win32 memory allocators, either malloc or free. has
anyone touched those recently? I've verified this crashes on win32, but when
trying to allocate memory with valid data and parameters.

can the reporter try daily builds and see what day this started to happen? It
could be anything.

Comment 15

[K Chayka]

build 2000121204 seems to be the last 'good' build before the view source
problems start. build 121220 crashes on the paste, but the crash is in xpcom.dll
instead of a win system dll. Lots of xpcom.dll crashes in 121220, and 1213
builds. :( The weirdness with eol characters in the copied text also starts with
121220.

Is this good enough, or should I keep searching for the first crash on a win dll?

Comment 16

[Mike Pinkerton (not reading bugmail)]

since the clipboard code didn't change until 12/18 (my checkin of
nsTranferable.cpp), if this became unstable before that date then this is a
problem with xpcom and it's memory allocators.

over to someone who might know.

Comment 17

[Mike Pinkerton (not reading bugmail)]

cc'ing vidur and jst, as their big string landing was 12/12, the date all this
started happening

Comment 18

[Mike Pinkerton (not reading bugmail)]

ok, taking this back after some more debugging. it appears that 
nsLinebreakHelpers::ConvertPlatformToDOMLinebreaks() is changing the data buffer 
ptr it returns to one that has already been deleted. the next attempt to free it 
blows up.

simon? any idea what could have changed here that would cause this routine to 
stop working and return trashed data?

Comment 19

[Mike Pinkerton (not reading bugmail)]

hrm, i was mistaken. it is passing back memory that looks ok (it's not trashed) 
but it still dies when you try to delete it. Any thoughts? We're both using 
nsMemory to alloc/free, so that shouldn't be a problem...

Comment 20

[Simon Fraser [no longer active]]

pink: you must be trashing the malloc heap somewhere.

Comment 21

[Simon Fraser [no longer active]]

oops, I need to read up a little

Comment 22

[Mike Pinkerton (not reading bugmail)]

*** Bug 64094 has been marked as a duplicate of this bug. ***

Comment 23

[Mike Pinkerton (not reading bugmail)]

*** Bug 56382 has been marked as a duplicate of this bug. ***

Comment 24

[Mike Pinkerton (not reading bugmail)]

*** Bug 64720 has been marked as a duplicate of this bug. ***

Comment 25

[Mike Pinkerton (not reading bugmail)]

after talking to vidur, it seems that on 12/12 or so, he changed how line
endings come out of the DOM. Previously, we assumed that all text from the DOM
had "\n" linefeeds. Now, it can have "\r\n" on win32.

I think the "right" way to fix this is to fix the DOM to return to its old
behavior and always give consistent line endings, regardless of platform.

What say you all?

Comment 26

[Mike Pinkerton (not reading bugmail)]

Attachment: use 'any' linebreaks on paste, not just platform

Comment 27

[Mike Pinkerton (not reading bugmail)]

attached a patch that fixes this on win32, and still works on macos. i'm not
exactly sure why this fixes everything, but i guess we were getting confused by
irregular line endings and converting from 'any' to 'dom' clears up the troubles.

i still think the DOM should go back to being consistent across all platforms.

Comment 28

[Akkana Peck]

Joining cc.  If the dom can now contain \r as well as \n, that potentially
breaks a lot of assumptions in editor and output since we've always been told
that we can rely on the dom having only \n.  There may be other things breaking,
as well; adding Brendan, who's been seeing a weird problem with newlines in text
areas when reloading or going back/forward.

Under what circumstances would we now see \r in the dom, aside from someone
writing JS to put it there explicitly (which was possible before, but unlikely)?

Comment 29

[Mike Pinkerton (not reading bugmail)]

r=saari, sr=sfraser. fix checked in. a new bug should be opened for further
discussion

Comment 30

[K Chayka]

Looks like the crash problem is fixed in build 2001011020. The weirdness with
eol characters is still there, so I guess that was coincidence after all. Is
there already a bug on this?

Comment 31

[A. Craig West]

There is something wierd in the line breaks, all right. I noticed today that I
am getting \r\r\n, in copy/paste operations. I believe that the windows
clipboard is actually the guilty party.
I'm looking for an appropriate bug for that

Comment 32

[K Chayka]

Is it perchance related to the parser problem noted in bug 63081? It started
happening at the same time.

Comment 33

[Akkana Peck]

Line breaks: Bugs 63081 and 65099 (and the various other dups).