210547 - Attempt to read news message, get null memory dereference crash

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Mark Pfeifer]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030624

This started happening with Mozilla 1.4RC2, and continues with the build listed 
above.  The full message is: The instruction at "0x61ac2773" referenced memory 
at "0x00000000".  The memory could not be "read".  The Netscape Quality Agent 
then appears.

I have a slightly unusual setup - I have two News accounts that point to the 
same server.  It's an internal corporate server, and I have set it up this way 
so that I can have the 'internal groups' post with one identity (my real name 
and e-mail), and I can post to 'external groups (real Usenet)' with a spam-
hidden identity.  I originally set this up under Mozilla 1.3, and have carried 
it forth in Mozilla 1.4.

I can use the "external" account with no problems - I can see messages, read 
them, etc.  If I try to read messages on the "internal" account, Mozilla simply 
crashes.

The only differences between the two accounts is the displayed name and the 
posting e-mail address - otherwise, they're identical (no passwords are 
required for our news server).

Note that I cannot duplicate this setup in Mozilla 1.4 - it won't allow me to 
create two News accounts talking to the same server.

Reproducible: Always

Steps to Reproduce:
1.Access the problem News account
2.Try to read a message
3.Mozilla crashes

Actual Results:  
Quality Feedback Agent appears.

Expected Results:  
Display the News message

Comment 1

[Frank Schönheit]

confirming.
I stumbled over this in a profile which uses a number of accounts, all working
on localhost, with different user names. In all of these accounts except one,
the attempt to read news crashes.

Comment 2

[Frank Schönheit]

found 210089 - I think this one here is a duplicate of bug 210089, but I'm not
going to mark it this way for now, since the original gave a different
description of the reasons ...

Comment 3

[Frank Schönheit]

The submitter of bug 210089 claimed that his bug is *not* about multiple
accounts reading from the same server, so this one here is no duplicate.

attachment 129459 [details] [diff] [review] fixes this bug here, unfortunately, I already attached it to
bug 210089, because it *also* fixes the symtopms (though probably not the
reasons) of #210089#.

Comment 4

[Asa Dotzler [:asa]]

not going to hold for this problem. let's see if it gets fixed by bug 210089

Comment 5

[Frank Schönheit]

re-requesting "blocking" flags, since Seth suggested to not mix the fix for this
bug here with the fix for bug 210089

Comment 6

[Frank Schönheit]

Attachment: patch

patch moved from bug 210089 to here
Will also come up with an alternative patch which also includes changed
behaviour for GetChildNamed (see bug 210089 comment 15 and bug 210089 comment
17), if not advised otherwise by seth.

Comment 7

[Frank Schönheit]

Attachment: patch Mk II

additionally changing nsIFolder::getChildNamed to not return success in case of
an unsuccessful lookup

Comment 8

[chris hofmann]

does anyone have a stack trace for this crash so we can correlate to talkback
data?   I guess we need reviews too..   we should try and pick this up for 1.5
final since we are almost out of time for 1.5b

Comment 9

[Frank Schönheit]

chris, I could probably reproduce this (I'd need to "borrow" a profile from the
person who encountered the crash on her machine). However, as far as I remember,
the stack was the one from bug 210089 comment 1 - definately crashing in
nsNntpService::GetFolderFromUri, while attempting to display a message.

If you need a more definite stack for the correlation, then please say and I'll
try (will probably only be by tomorrow, or next week).

Comment 10

[Frank Schönheit]

Comment on attachment 130000 [details] [diff] [review]
patch Mk II

bienvenu, if you'd find some time ... that's the patch you already saw for bug
210089, plus a change to GetChildNamed, plus the adjustment of one caller of
this method (the other places did't look (to me) as if they needed it).

In case you say this patch is the wrong place to address the GetChildNamed
thingie, please think of my review request as applied to attachment 129998 [details] [diff] [review] :)

Comment 11

[David :Bienvenu]

Comment on attachment 130000 [details] [diff] [review]
patch Mk II

this looks ok, thx, Frank

Comment 12

[Asa Dotzler [:asa]]

1.5b shipped. moving request forward.

Comment 13

[chris hofmann]

might be a good one to nab for 1.5 final.  looks like it just needs sr=

Comment 14

[Frank Schönheit]

Comment on attachment 130000 [details] [diff] [review]
patch Mk II

requesting approval for 1.5. The bug here renders newsgroup access effectively
useless for people having n-to-1 account-server relations, and is a major
regression in 1.4, IMO.

Comment 15

[Asa Dotzler [:asa]]

Comment on attachment 130000 [details] [diff] [review]
patch Mk II

a=asa (on behalf of drivers) for checkin to Mozilla 1.5

Comment 16

[David :Bienvenu]

fix checked in; thx, Frank.