156187 - mail crashes when trying to view source of a message when I'm offline [@ nsImageBoxFrame::UpdateImage]

Status: RESOLVED WORKSFORME

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[Sven Krohlas]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.1a+) Gecko/20020707
BuildID:    2002070704

Crash when viewing messages, I' attach a testcase.

Reproducible: Always
Steps to Reproduce:
1. go offline
2. open message
3. go to view -> message source

Actual Results:  crash

Expected Results:  well, try to guess ;)
Right! It shouldn't crash and show me the source.

I found this as I wanted to view the source of a message which subject
started with "°°°°°°°°". I tried to reproduce it, and it only worked
with this one message, as I found out because I was online.
I sent myself 2 messages: one in ISO-8859-15 one in -1, I get the
crash with both when I'm offline.

Talkback IDs:
TB8092874E
TB8093960W
TB8094159M
TB8094175E

Comment 1

[Sven Krohlas]

Attachment: with this messages the crash occurs

Here's one of my 2 simple testcases

Comment 2

[Boris Zbarsky [:bzbarsky]]

Two of the incidents have no stack, the other two are:

0x00000000
nsImageBoxFrame::UpdateImage()
nsImageBoxFrame::DidSetStyleContext()
FrameManager::ReResolveStyleContext()
FrameManager::ReResolveStyleContext()
FrameManager::ComputeStyleChangeFor()
nsCSSFrameConstructor::AttributeChanged()
StyleSetImpl::AttributeChanged()
PresShell::AttributeChanged()
nsXULDocument::AttributeChanged()
nsXULElement::SetAttr()
nsXULElement::SetAttr()
nsXULDocument::AttributeChanged()
nsXULElement::SetAttr()
nsXULElement::SetAttribute()
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod()
XPC_WN_CallMethod()
js_Invoke()
js_Interpret()
js_Invoke()
nsXPCWrappedJSClass::CallMethod()
nsXPCWrappedJS::CallMethod()
PrepareAndDispatch()
nsXPTCStubBase::Stub3()
nsEventListenerManager::HandleEventSubType()
nsEventListenerManager::HandleEvent()
GlobalWindowImpl::HandleDOMEvent()
nsXULDocument::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleChromeEvent()
GlobalWindowImpl::HandleDOMEvent()
DocumentViewerImpl::LoadComplete()
nsDocShell::EndPageLoad()
nsWebShell::EndPageLoad()
nsDocShell::OnStateChange()
nsDocLoaderImpl::FireOnStateChange()
nsDocLoaderImpl::doStopDocumentLoad()
nsDocLoaderImpl::DocLoaderIsEmpty()
nsDocLoaderImpl::OnStopRequest()
nsLoadGroup::RemoveRequest()
nsStreamIOChannel::OnStopRequest()
nsOnStopRequestEvent::HandleEvent()
nsARequestObserverEvent::HandlePLEvent()
PL_HandleEvent()
PL_ProcessEventsBeforeID()
processQueue()
nsVoidArray::EnumerateForwards()
nsAppShell::ProcessBeforeID()
handle_gdk_event()
libgdk-1.2.so.0 + 0x17dd4 (0x4035ddd4)
libglib-1.2.so.0 + 0x10c46 (0x4038fc46)
libglib-1.2.so.0 + 0x11273 (0x40390273)
libglib-1.2.so.0 + 0x1143c (0x4039043c)
libgtk-1.2.so.0 + 0x9276c (0x402a876c)
nsAppShell::Run()
nsAppShellService::Run()
main1()
main()
libc.so.6 + 0x1d7ee (0x404ba7ee) 


Looks a lot like bug 92368 (very similar reproduction conditions)

Comment 3

[grylchan]

using commercial trunk 2002070108  on NT 4.0,
commercial trunk on linux 2.2
 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020708 
& commercial branch on  NT 4.0
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.1) Gecko/20020708

I can't reproduce this crash. I tried the users email 
and it didn't crash for me.
I tried saving the email in my imap mail folder and local folders.
Viewing source online/offline in both imap/local folders and couldn't
bring up the crash.

Comment 4

[grylchan]

reporter, anything else you can add?
I tried changing the char setting to ISO-8859-15
and send myself a mesg and I couldn't crash.
That email you attached looks rather ordinary.
Nothing that stands out as to why it would crash.

will mark as works for me if I can't reprdouce.

Comment 5

[Sven Krohlas]

It could be possible that the crash is caused by the enigmail plugin I'm using,
I'll send the author a link to this bug in a few minutes.
Anyway i had no problem to reproduce this bug this morning.

Comment 6

[David :Bienvenu]

is this an imap, news, or local mesage you're trying to look at while offline?

Comment 7

[Sven Krohlas]

Mail to Enigmail author is out, here are a few more Talkback-IDs, I hope this
can help:

using the attached testcase:
TB8113069H
TB8113031H

using the original message that showed the bug for the first time:
TB8112998K

As you can see I still can reproduce it perfectly :-(

Comment 8

[grylchan]

in addition to David's question in comment 6
when you view the mesg source of these mesgs
what's in these mesgs? attachments? Html? Web pages?
links? Just plain text mesgs?

Comment 9

[Sven Krohlas]

It's a local plain text message, like the one I've attached.

Comment 10

[David :Bienvenu]

then this is not an offline mail bug, and not my bug. I suspect it has something
to do with the enigmail plugin, and I wonder if it tries to actually make a
network connection while offline - such connections fail synchronously and that
causes some problems with gecko sometimes.

Comment 11

[Sven Krohlas]

Ok, I re-installed Mozilla now (good-bye Enigmail...) and it still happens:
TB8113955H
I'll try out my 2 days old CVS debug build and then catch some sleep.

Comment 12

[David :Bienvenu]

what's the name of the folder the local message is in? Is it just the INBOX or
is it some special folder name? I'm grasping at straws here - viewing the
message source of a local message shouldn't care if you're online, offline, or
on the moon.

Comment 13

[Sven Krohlas]

Ir's in my INBOX, it also happens with the testcases I moved to the trash-folder.
My CVS-build shows the same behaviour, I'll attach the whole command line output.

Comment 14

[Sven Krohlas]

Attachment: ouptut of my 2 days cvs build

what I did:
-started Mozilla
-opened MailNews
-going offline
-opened INBOX
-selected Message
-view -> Message source
=>and it immediately crashed

Comment 15

[David :Bienvenu]

if you do this in the debugger, can you tell what the image request uri is?    
nsresult rv = mImageRequest->GetURI(getter_AddRefs(requestURI));

also, which skin are you using (classic or modern)? 

Comment 16

[grylchan]

I can't reproduce crash w/comment 14 on linux 2.2 w/trunk (7/8) build.
I tried viewing source of all types of mesgs and no dice.

I searched our talkback database. I looked for
nsImageBoxFrame::UpdateImage() and I did find crashes that
had same stack trace. but not very conistent as the dates
vary (6-8 to now). What was interesting is this only OCCURS
in linux builds. All crashes were on linux only.
But sadly no conistent steps to reproduce (closing 
bunch of pop up ads caused crash or file|new window)

Comment 17

[David :Bienvenu]

Gary, is there a bug filed for these other talkback crashes? If so, this is
probably a dup of that bug, and this might help someone else reproduce this crash.

Comment 18

[grylchan]

Unfortunately David, when I did a query on bugzilla
for that stack trace, the only bug that has it, is this one.
I can add talkback people to the cc list and maybe they can help?

Comment 19

[David :Bienvenu]

we should put the stack trace in the summary so that it will show up in the
talkback queries, and probably reassign this to someone like pav, since it's
crashing in the image layout code.

Comment 20

[grylchan]

reassigning to pav based on David's comments, changing component.
Making sumarry line shorter
mail crashes when trying to view source of a message with subject starting with 
"°°°°°°" when I'm offline [@ nsImageBoxFrame::UpdateImage]

Comment 21

[grylchan]

Attachment: html talkback page of all crashes w/nsImageBoxFrame::UpdateImage(

Comment 22

[Sven Krohlas]

comment #15: It happens in modern, I tried classic, and there it works.
[After switsching back to modern and restarting Mozilla Talkback appeared. I
don't know why, I had no crash, I'll see if i can reproduce it.]
Ok, I'll try to cope with the debugger ;)

Comment 23

[Sven Krohlas]

About the debugger:
I tried ./mozilla -g
[gdb started...]
run
[a few minutes later]
Program exited normally.
Is it possible I don't have enough RAM to debug it? I haven't even seen one
window of Mozilla.
----------------------
The Problem in Classic:
I have also found a way to reproduce it here, it's a bit different:
I tried the following:
-start Mozilla
-start MailNews
-going offline
-view message (the original message with that the crash occured for the first
time)
-view message source (NO crash)
-quit
=>Crash
Talkback-IDs: TB8131224G - TB8131229E

Then I tried the same, but quit Mozilla after viewing the message, I didn't
have a look at the sources of the message:
TB8131242K - TB8131237K

It doesn't work with "normal" messages, and only when I'm offline.
This one is getting quite obscure (I hope this is the right English word),
I think.

Comment 24

[grylchan]

Reporter,
I can reproduce your crash in comment 23 BUT it's totally
different bug. My talkback ids are 8146931 & 8147068. Using
2002070808 on linux 2.2. What happens is when you quit,
mozilla quits, but the process is still running.

The stack trace is different from original bug:

libpthread.so.0 + 0x7d38 (0x40203d38) 
libc.so.6 + 0x7498b (0x4051198b) 
PL_strfree() 
nsSocketTransportService::ClearEntry() 
PL_DHashTableFinish() 
nsSocketTransportService::Shutdown() 
nsIOService::SetOffline() 
nsIOService::Observe() 
nsObserverService::NotifyObservers() 
NS_ShutdownXPCOM() 
main() 
libc.so.6 + 0x1d7ee (0x404ba7ee) 

you're original bug is not reproducable.

Comment 25

[Sven Krohlas]

If you can't reproduce it... don't waste your time then and fix up the other one
(or is there anything left I can do to help you?).
Strange day, I try to reproduce a crash and discover another one...

Comment 26

[grylchan]

filed bug 156581 off reporters problem in comment 23.

I'll let pav, terri, or David decide if they want
to mark the original bug as works for me?

Comment 27

[Cristian Seres]

I have been able to reproduce a bug that has quite a bit in common with this bug
(Offline mode, nsImageBoxFrame::UpdateImage). OS is Mac OS X 10.1.5. Mozilla 1.1
beta.

The crash occurs when I choose Offline mode and browse to a page that I have
been previously visited. Mozilla crashes when I click a link that should open a
new window showing a jpg image. The page is
http://www.essemobel.fi/fin/ei-ketju/fria.htm and the link named 'RUSTICAL pöytä'.

Here is a clip from Mozilla crash.log:

Thread 0 Crashed:
 #0   0x04056dec in 0x4056dec
 #1   0x029f7220 in nsImageBoxFrame::UpdateImage(nsIPresContext *, int &)
 #2   0x029f7928 in nsImageBoxFrame::DidSetStyleContext(nsIPresContext *)
 #3   0x029ce238 in 0x29ce238
 #4   0x029ce780 in ReResolveStyleContext__12FrameManagerFP14nsIPresContextP8nsIFr
 #5   0x029ce95c in ComputeStyleChangeFor__12FrameManagerFP14nsIPresContextP8nsIFr
 #6   0x0299067c in AttributeChanged__21nsCSSFrameConstructorFP14nsIPresContextP10
 #7   0x020e77dc in AttributeChanged__12StyleSetImplFP14nsIPresContextP10nsIConten
 #8   0x028ab1e8 in AttributeChanged__9PresShellFP11nsIDocumentP10nsIContentiP7nsI
 #9   0x02369244 in nsXULDocument::AttributeChanged(nsIContent *, int, nsIAtom
*, int, int)
 #10  0x023aae20 in nsXULElement::SetAttr(nsINodeInfo *, nsAString const &, int)
 #11  0x023aafc4 in nsXULElement::SetAttr(int, nsIAtom *, nsAString const &, int)
 #12  0x02369140 in nsXULDocument::AttributeChanged(nsIContent *, int, nsIAtom
*, int, int)
 #13  0x023aae20 in nsXULElement::SetAttr(nsINodeInfo *, nsAString const &, int)
 #14  0x023a5cd0 in nsXULElement::SetAttribute(nsAString const &, nsAString const &)
 #15  0x005bcd0c in XPTC_InvokeByIndex
 #16  0x005bcc00 in XPTC_InvokeByIndex
 #17  0x01a004f4 in 0x1a004f4
 #18  0x01a0699c in XPC_WN_CallMethod(JSContext *, JSObject *, unsigned int,
long *, long *)
 #19  0x0197fc4c in js_Invoke
 #20  0x01987cf4 in 0x1987cf4
 #21  0x0197fca4 in js_Invoke
 #22  0x019f9cd8 in 0x19f9cd8
 #23  0x019f5fe4 in CallMethod__14nsXPCWrappedJSFUsPC15nsXPTMethodInfoP17nsXPTCMin
 #24  0x005bd18c in PrepareAndDispatch

...ask if you want more info.

Comment 28

[grylchan]

I can reproduce using web link in comment 27 using commercial
branch 8/23 on NT 4.0

It's javascript pop up window link.

I think the key is to view a web page that has javascript
open window links, go to another web page, go offline,
go back to the page w/javascript open window links, and
click on them to bring up the crash. In other words
the javascript open window link shouldn't be cached.
If it's cached then there are no crashes.

I did this once with a cnn javascript web page
(tb id 9893972).

Antoher talkback id 9893513

It's hard to reproduce constantly on a page other than the
one in comment 27.

First talkback:

0x038d896c 
imgLoader::CreateNewProxyForRequest 
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgLoader.cpp, line 517] 
imgLoader::LoadImage 
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgLoader.cpp, line 406] 
nsImageBoxFrame::UpdateImage 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsImageBoxFrame.cpp, line 462] 
nsImageBoxFrame::DidSetStyleContext 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsImageBoxFrame.cpp, line 577] 
nsIFrame::SetStyleContext [..\..\..\..\dist\include\layout\nsIFrame.h, line 553] 
FrameManager::ReResolveStyleContext 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1802] 
FrameManager::ReResolveStyleContext 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1979] 
FrameManager::ComputeStyleChangeFor 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 2023] 
nsCSSFrameConstructor::AttributeChanged 
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor


2nd Talkback:
0x1f8898c2 
nsImageBoxFrame::DidSetStyleContext 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsImageBoxFrame.cpp, line 577] 
nsIFrame::SetStyleContext [..\..\..\..\dist\include\layout\nsIFrame.h, line 553] 
FrameManager::ReResolveStyleContext 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1802] 
FrameManager::ReResolveStyleContext 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1979] 
FrameManager::ComputeStyleChangeFor 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 2023] 
nsCSSFrameConstructor::AttributeChanged 
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, 
line 10778] 
StyleSetImpl::AttributeChanged 
[d:\builds\seamonkey\mozilla\content\base\src\nsStyleSet.cpp, line 1588] 


Common file in all stack traces is:
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsImageBoxFrame.cpp, line 577] 

Comment 29

[Sven Krohlas]

I'm no longer able to reproduce this, using Mozilla/5.0 (X11; U; Linux i586;
en-US; rv:1.7a) Gecko/20040117
Marking WFM, cry out loud if your opinion is different ;)