139362 - hang in copy_string while forwarding epost (HTML format ) as Inline !!

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Yeh You-Ying]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020422
BuildID:    2002042209

Recent nightlies, even RC1, can not forward(inline) epost (HTML format) as before.
The Mozilla ate lots resource. I should kill the process of Mozilla.

Reproducible: Always
Steps to Reproduce:
1. Forward epost(epaper I subscribe) as Inline
2. The epost message source is attached to Bugzilla


Actual Results:  Forward successfully and system not hang.

build 2002-04-15
build 2002-04-17
build 2002-04-19
build 2002-04-22
RC1                     
all have the same problem.

Comment 1

[Yeh You-Ying]

Attachment: The epost source I would like to forward as inline

Comment 2

[Yeh You-Ying]

Attachment: The epost looks like

Comment 3

[Yeh You-Ying]

Attachment: forward as inline

Comment 4

[R.K.Aa.]

related: bug 126953

Comment 5

[Trix Supremo]

wfm using mozilla trunk build 2002042303.  forwarding attachment as inline can
be sent and received successfully.  please reverify using latest trunk build.

Comment 6

[Yeh You-Ying]

Dear Trix,

I can not verify what you said, because nightly 2002042303 (win) can not be
downloaded completely.
The file seems to be broken.

Comment 7

[Yeh You-Ying]

Still not fixed in 2002042510. (0.9.9+)
This bug needs more attention. :-(
The function was OK in 0.9.9 milestone.

Comment 8

[[e-mail]]

Well, at least in Classic (I don't use Modern), I see the green arrow on the
mail icon to show that you have new mail. If that's a problem with modern you
should file a themes bug. Also, I filed the bug asking for the mail icon to go
to read your new mail some time ago but it as been ignored.

Comment 9

[[e-mail]]

Um, somehow I attached this to the wrong bug by mistake. So sorry...

Comment 10

[Yeh You-Ying]

I have to correct what I said.
The milestone 0.9.9 also failed in this. I have checked it again.
This should be a big problem of Mozilla Mail, but it seems no one care...:(

Comment 11

[Yeh You-Ying]

I doubt if it is the size problem of HTML message I'd like to forward...????

Comment 12

[Jean-Francois Ducarroz]

Accepting

Comment 13

[Yeh You-Ying]

Attachment: This simple HTML could not be forward as inline....

Comment 14

[Yeh You-Ying]

Attachment: Simple HTML source which could not be forward as inline. Mozilla looks like stalled.

This bug needs some one's attention....:-(

Comment 15

[Yeh You-Ying]

Mozilla 0.9.9+ build 2002050108 still has this issue.

Comment 16

[esnible]

Attachment: HTML spam I received which hung MozRC1 when forwarding inline

Another test case for the bug.	This is some spam I received.  When I forward
as attachment all is well.  When I forward as inline Mozilla RC1 hangs, under
both Linux and Win2000, and CPU usage goes to 100%.

Comment 17

[Yeh You-Ying]

Attachment: Another message can not be forwarded as inline.

Comment 18

[Jean-Francois Ducarroz]

Using the first test case, I am able to reproduce the hang with a recent debug
build. The hang append at:

nsButtonBoxFrame::MouseClicked(nsIPresContext * 0x054144e0, nsGUIEvent *
0x0012f400) line 192
nsButtonBoxFrame::HandleEvent(nsButtonBoxFrame * const 0x055a0308,
nsIPresContext * 0x054144e0, nsGUIEvent * 0x0012f400, nsEventStatus *
0x0012f6e0) line 142
PresShell::HandleEventInternal(nsEvent * 0x0012f400, nsIView * 0x00000000,
unsigned int 0x00000001, nsEventStatus * 0x0012f6e0) line 6001 + 38 bytes
PresShell::HandleEventWithTarget(PresShell * const 0x053bd730, nsEvent *
0x0012f400, nsIFrame * 0x055a0308, nsIContent * 0x05357348, unsigned int
0x00000001, nsEventStatus * 0x0012f6e0) line 5955 + 22 bytes
nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const
0x052c8670, nsIPresContext * 0x054144e0, nsMouseEvent * 0x0012f8d4,
nsEventStatus * 0x0012f6e0) line 2623 + 63 bytes
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x052c8678,
nsIPresContext * 0x054144e0, nsEvent * 0x0012f8d4, nsIFrame * 0x055a0308,
nsEventStatus * 0x0012f6e0, nsIView * 0x053f5c90) line 1703 + 28 bytes
PresShell::HandleEventInternal(nsEvent * 0x0012f8d4, nsIView * 0x053f5c90,
unsigned int 0x00000001, nsEventStatus * 0x0012f6e0) line 6006 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x053bd734, nsIView * 0x053f5c90,
nsGUIEvent * 0x0012f8d4, nsEventStatus * 0x0012f6e0, int 0x00000001, int &
0x00000001) line 5909 + 25 bytes
nsViewManager::HandleEvent(nsView * 0x053f5c90, nsGUIEvent * 0x0012f8d4, int
0x00000001) line 2076
nsView::HandleEvent(nsViewManager * 0x05242bb0, nsGUIEvent * 0x0012f8d4, int
0x00000001) line 306
nsViewManager::DispatchEvent(nsViewManager * const 0x05242bb0, nsGUIEvent *
0x0012f8d4, nsEventStatus * 0x0012f7d0) line 1881 + 23 bytes
HandleEvent(nsGUIEvent * 0x0012f8d4) line 83
nsWindow::DispatchEvent(nsWindow * const 0x053f5d3c, nsGUIEvent * 0x0012f8d4,
nsEventStatus & nsEventStatus_eIgnore) line 865 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f8d4) line 886
nsWindow::DispatchMouseEvent(unsigned int 0x0000012d, unsigned int 0x00000000,
nsPoint * 0x00000000 {x=??? y=???}) line 4720 + 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 0x0000012d, unsigned int
0x00000000, nsPoint * 0x00000000 {x=??? y=???}) line 4977
nsWindow::ProcessMessage(unsigned int 0x00000202, unsigned int 0x00000000, long
0x0025006d, long * 0x0012fcec) line 3596 + 28 bytes
nsWindow::WindowProc(HWND__ * 0x000f0870, unsigned int 0x00000202, unsigned int
0x00000000, long 0x0025006d) line 1130 + 27 bytes
USER32! 77e11b60()
USER32! 77e11cca()
USER32! 77e183f1()
nsAppShellService::Run(nsAppShellService * const 0x01148ad8) line 451
main1(int 0x00000001, char * * 0x00304fc0, nsISupports * 0x00000000) line 1456 +
32 bytes
main(int 0x00000001, char * * 0x00304fc0) line 1805 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e8d326()

the assertion is:
###!!! ASSERTION: You can't |write| into an |nsWritingIterator| with no space!:
'size_forward() > 0', file ..\..\dist\include\string
\nsStringIterator.h, line 356
###!!! ASSERTION: |copy_string| will never terminate: 'count_copied > 0', file
..\..\dist\include\string\

Comment 19

[Jean-Francois Ducarroz]

The hang append during the send. Therefore this is a dataloss

Comment 20

[Jean-Francois Ducarroz]

we choke on the HTML tag <img src="clear.gif" height=1 width=150> when
processing the image url. This is similar to bug 129358 I fixed a while ago

Comment 21

[Jean-Francois Ducarroz]

this is a string iterator problem! the function OutputIterator&
copy_string( InputIterator& first, const InputIterator& last, OutputIterator&
result ) will failed to detect the end of the copy. This because when we copied
the first chunk of data, we move forward the "first" iterator using the function
source_traits::advance(first, count_copied). The returned iterator will be set
pass the end operator by the call to normalize_forward(). Therefore we never get
a first iterator equals to the "last" iterator and we loop for ever!!!

reassign to string guru.

Comment 22

[Jean-Francois Ducarroz]

the easy way to reproduce this problem is:

1) Open a Plain Text compose window
2) address the message to yourself and type the following text:
<img src="bogus.gif"
3) send the message
4) get the message, do forward inline, address the message to yourself
5) send it
 ==> Application hang

PS: The fact we interprete HTML tag from a plain text message when forwarding is
covered by another bug report

Comment 23

[Jean-Francois Ducarroz]

in step 2, you should read:

2) address the message to yourself and type the following text:
<img src="bogus.gif">

the HTML tag must be closed with a >

Comment 24

[Samir Gehani]

Nav triage team: nsbeta1+, adt2 rtm

Comment 25

[Yeh You-Ying]

Attachment: A message contains *no* HTML tag, still hang...

This attachment message is *not* HTML like message (no HTML tag), also can not
be forwarded inline.

Comment 26

[Jean-Francois Ducarroz]

This hang is caused by the way fragment are currently managed in strings. This
problem should go away once the fix for bug 70083 has been checked in. Until
then, jag gave me a work around that I will post...

Comment 27

[Jean-Francois Ducarroz]

Attachment: Proposed fix by Jag, v1

The workaround is to copy the string we need to parse into an new string, that
will result in an unfragmented string.

Comment 28

[Jean-Francois Ducarroz]

Comment on attachment 83052 [details] [diff] [review]
Proposed fix by Jag, v1

R=ducarroz

Comment 29

[(not reading, please use [e-mail] instead)]

Comment on attachment 83052 [details] [diff] [review]
Proposed fix by Jag, v1

sr=sspitzer

if you check this into the trunk, don't forget to add a comment to #70083 to
remember to remove the hack once that bug is fixed.

Comment 30

[Jean-Francois Ducarroz]

Fix checked in the trunk. This is a simple fix that prevent an application
freeze, we should consider taking it for RTM

Comment 31

[scottputterman]

adding adt1.0.0+.  Please get drivers approval and then checkin to the 1.0 branch.

Comment 32

[Yeh You-Ying]

Hello,

In nighty, 2002051408 on Win98SE, the fix works.
But while sending message...it looks quite slow...:-(
It's better to avoid this in a mature S/W application.

Comment 33

[Yeh You-Ying]

Although the fix can forward HTML style email, it seems to need lots of
resource...i.e., the whole system
becomes slow while sending. 

And there is still a problem. While entering email address, the smart searching
in address book no more works !  It looks  not a perfect fix.

Thanks for your effort.

Comment 34

[Jean-Francois Ducarroz]

That should be a totally different problem and not a regression caused by this
fix. Please file a new bug.

Comment 35

[Yeh You-Ying]

I filed an another bug about this fix issue.
Please refer to bug#144658

Thanks a lot.

Comment 36

[Jean-Francois Ducarroz]

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

Comment 37

[Brendan Eich [:brendan]]

Comment on attachment 83052 [details] [diff] [review]
Proposed fix by Jag, v1

a=[e-mail] for 1.0 -- please get this in ASAP.

/be

Comment 38

[Jean-Francois Ducarroz]

Fix checked in the branch

Comment 39

[Yeh You-Ying]

In nightly 2002051708 (1.0.0+), forwarding HTML style message as inline (also
attachment) comsuned lots resource, and entering email  address with smart
searching failed (except forward as attachment). I'm not sure this is closed or
not. I filed bug#144658 for this, if this is considered to solve in RC3 (or 1.0
final), please notice the related problem. Personal thinking, this isn't a
perfect fix and it should not appear
in a final release...because it's an obvious issue.

Thanks for your all effort. 

ps. This may be an impolite question, but is this fix really verified ? 

Comment 40

[Yeh You-Ying]

Attachment: This pic shows the problem of fix.

After using this fix (I believe that's in RC3), you will see the terrible
result as the pic.
This pic was got from RC3.

Comment 41

[jag (Peter Annema)]

This bug is about a hang in string code. The work-around for this was to
construct the resulting string slightly differently, the resulting string
contains the same characters either way. This bug has been fixed; as far as I
know, we don't hang anymore.

This fix can't possibly affect (either positively or negatively) the issues you
describe. Could you please keep comments about them in the bug you filed instead
of putting them in this bug?

Comment 42

[Jan Jiing-Yau]

Hello Peter Annema,

First I have say sorry for my poor English. I might not describe well.
What I want to point out is, this fix (or said work-around) does not *perfectly*
solve this issue.
I knew that MozillaMail will not hang with this work-around.
But a viewpoint from an *end* *user* about this work-around, it's hard to say it
was solved completely. (Please refer to the attachment, 86038) 
I can imagine that Mozilla team will say "This is another problem, please file
another bug".
Yes! I did that, it's bug#144658. Any one in Mozilla team care ? I'm not sure
and I don't know...

I'm an end user in this domain, I filed this bug just to help Mozilla.org to
qualify.
Please don't say Bugzilla is not for end user. 

Sorry to say that, I feel tired and frustration to file bugs about
MozillaMail/News recently.
I filed bugs, and lots of them still have no progress...
Becasue they are minor ???  
Sorry to complian this, you may not be interested in this complaint or heard
lots already.

>> Could you please keep comments about them in the bug you filed instead
>>of putting them in this bug?

Sorry...I have poor English, I don't know what you mean above.

Comment 43

[jag (Peter Annema)]

I understand that end users may think this bug is not fixed, which is why I've
tried to explain why we developers think this particular bug is fixed. Mail
doesn't hang anymore when it forwards a message inline (even though it's still
slow and uses a lot of resources). If you look at your first comment, your
expected results (under the actual results line) even state "Forward
successfully and system not hang."

I have fixed the hang part of this problem, it is up to the mail/news team to
fix the rest of the problems. The easiest way to get that fixed is to file a new
bug (which you have done, bug 144658) and discuss the problems there. They may
not fix it immediately, they have a long list of bugs to fix and they probably
have bugs with a higher priority than the ones you've pointed out.

Please keep filing bugs you find, it is appreciated, even though we may not have
the resources to fix them immediately, some bugs are more important to fix than
other bugs, and will get fixed first.