Closed Bug 40266 Opened 24 years ago Closed 24 years ago

Reading message problem during INBOX display

Categories

(MailNews Core :: Networking: IMAP, defect, P3)

Product:
MailNews Core
Component:
Networking: IMAP
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: BenB, Assigned: mscott)

References

Details

(Whiteboard: [nsbeta3-][nsbeta2-])

Attachments

(2 files)

The last lines of IMAP:5 before crash. Not sure, if they are helpful :-(.
7.79 KB, text/plain
Details
Log entries written between request to open msg and shutdown
977 bytes, text/plain
Details 
Split-off from bug 40020.

It happes shortly before the
INBOX content is shown. It is (fortunately!) not 100% reproducable. The first
two startes, is crashes often, the next starts, the content often shows up, but
I can't open a msg and the throbber spinns infinitely. All following starts work
most of the time. The whole game restarts, if I don't start Mozilla for a while.

I usually start mailnews directly per -mail (only rarely start the browser
directly).

It's (mostly likely) *not* a mem problem. I started with the the script

bash$ cat mozilla/start_mail.sh
export MEMHOG=1
cd /usr/src/mozilla/dist/bin
./mozilla -mail
Severity: normal → critical
Keywords: crash
Ben, can you give me a stack trace or something that shows where you are
crashing? I'm assuming you are using IMAP with an MS Exchange server right?
Component: Mail Back End → Networking - IMAP
Keywords: nsbeta2
mscott, I'm running an optimized build (was sick of gdb, bad performance and the
"special debug features" like profile selector :) ).

I can try to give you can IMAP log, if that helps?
yes, can you get an IMAP log?
QA Contact: lchiang → huang
BTW: Yes. this crash was just after the startup. Dunno, why there's only old
crap. (My IMBOX has less than 60 msgs.)
Cannot tell which IMAP server are you using from the log file, can you provide 
the log with the server info here?
UW-IMAP (4.5, I think)
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
> the next starts, the content often shows up, but I can't open a msg and the
> throbber spinns infinitely

Sometimes, the throbber for the main window (i.e. thread pane, the msg pane is
closed) spins infinitely, but more often, this one is fine and the one in the
standalone msg window spins infinitely and the msg doesn't show up.

In the latter case, the canvas is immediately rendered white (my default
background color). If everything is fine (no bug appears), it needs 0,5 - 1 s
until the background draws together with the msg content.

This appears much more often than the crash and is starting to block me
(assuming there is much to block :) ). Sometimes, I have to start Mailnews 10
times or so until I get a working instance.

I'm not sure, the infinite spins and the crash are related, but it seems so to
me.

If there's any info I can give you, tell me.
Now, I have a new variation of the bug: For one msg, the headers load and
obviously also a part of the body*, but then the infinite spin again. Other,
also longer, msgs seem to load fine.

*I have a printf in mimetpla, which outputs the generated HTML. I see on the
console e.g.

<div class=text-plain wrap=true graphical-quote=true style="font-family:
adobe-elvetica-iso8859-1; font-size: 14px;"><pre wrap>(Tired of this old junk? 
Thereis a new experimental email scheme in
Bugzilla.  If you're feeling brave, you can try it by turning on the
new pref at <a class="txt-link txt-link-freetext"
href="http://bugzilla.mozillaorg/userprefs.cgi?bank=diffs">http://bugzilla.mozilla.org/userprefs.cgi?bank=difs</a>)

<a class="txt-link txt-link-freetext"
href="http://bugzilla.mozilla.org/show_bu.cgi?id=10549">http://bugzilla.mozilla.org/show_bug.cgi?id=10549</a>

*** shadow/10549	Wed Apr 12 00:45:07 2000
--- shadow/10549.tmp.5661	Wed May 10 15:42:58 2000
***************
*** 3,9 ****
  Version: other
  Platform: All
  OS/Version: other
! Status: RESOLVED   
  Resolution: FIXED
  Severity: normal
  Priority: P3
--- 3,9 ----
  Version: other
  Platform: All
  OS/Version: other
STYLE CHANGE REFLOW. Blowing away all box caches!!
STYLE CHANGE REFLOW. Blowing away all box caches!!
STYLE CHANGE REFLOW. Blowing away all box caches!!
STYLE CHANGE REFLOW. Blowing away all box caches!!
Target nominated bugs to M16.  Please update as necessary.
Target Milestone: --- → M16
With the latest builds (May 28+), I still see the crash (sometimes), but not the
infnite spin: The INBOX content never shows up. Msg count shows: Unread 1 (which
is wrong), Total 0.
I'm getting constant crashes on Win32/M16-05-25. I can enter the password, but 
my INBOX won't show - instead, I'm getting a nice crash. I've reported it a few 
times using the talkback.
Christian, do you use IMAP? If yes, do you know the server implementation?


If I rip my ImapMail dir, the bug disappears for the next <~5 starts.
We're using SUN's imapd - an old version from 1997, I think it's 2.0.
I'll try removing the ImapDir again (running M160531 build). It did not
help in the past.
Nope, didn't work. It's still crashing.
'Qapl'ah! (sp?) Yes! Did you fix something?
The 060500 build of M16 Win32 Talkback seems to work. I can reliably start up
Messenger, and it reads the entire INBOX.
I'm not getting anything under Local Folders (for some reason) :^[
I'll try to remove the entire 'Mail' folder and see what happens.

Questions:

1) Are you using new profile or migrated profile?
2) Have you both removed ~/install_directory/package/defaults/pref/config-ns.js? 
(there is bug 34871 for start page problem, have you both removed above file 
alreay?)

My results (with config-ns.js)removed  are:
1) If used migrated profile, I had problem.
2) If I used new profile and without setting "Mail/" IMAP directory -- no 
problem for bring up the Inbox messages.
3) if I used new profile and used "Mail/" IMAP directory -- had problem for 
reading message from message body (I will log another bug then if this is 
another bug)

But, I didn't get crash yet based on the above setting/scenarios.....

Also, isn't "Mail/" IMAP directory only apply to UW IMAP? Why need to test on 
SUN with this setting?

I think we misunderstand each other. Let me clarify:
The default "user profile" comes up with Local Folders residing in
$PROFILE_DIR/Mail/*
In 4.72, that directory contains several files: Sent, Trash, Drafts, ....
For some reason, nothing's showing up in that directory. When sending mail,
I've turned on "add to Local Folders/Sent" and that crashes Messenger
(after the Email was sent).
This may be a different bug altogether.
Oh! I see. I did get a crash out of five times for trying to read Inbox messages 
in IMAP UW server....I logged bug 41622 for tracking messages are not displaying 
on message body already. I will try to get the talkback report and attach here 
then.
For the record: I *do* use a subdir on my UW-IMAP server and in advanced prefs.
Talkback#11840213:

Stack Trace

ld-linux.so.2 + 0x47 (0x40000047) 
libraptorhtml.so + 0x37a085 (0x40cd0085) 
libraptorhtml.so + 0x383683 (0x40cd9683) 
libraptorhtml.so + 0x38325e (0x40cd925e) 
libraptorhtml.so + 0x35b0ad (0x40cb10ad) 
libraptorhtml.so + 0x359dc9 (0x40cafdc9) 
libraptorhtml.so + 0x36420e (0x40cba20e) 
libraptorhtml.so + 0x35d0c3 (0x40cb30c3) 
libraptorhtml.so + 0x359dc9 (0x40cafdc9) 
libraptorhtml.so + 0x36420e (0x40cba20e) 
libraptorhtml.so + 0x363d21 (0x40cb9d21) 
libraptorhtml.so + 0x354d20 (0x40caad20) 
libraptorhtml.so + 0x1c6da7 (0x40b1cda7) 
libraptorhtml.so + 0x1fa92b (0x40b5092b) 
libraptorhtml.so + 0x1d5594 (0x40b2b594) 
libraptorhtml.so + 0x1ece94 (0x40b42e94) 
libraptorhtml.so + 0x1ebc15 (0x40b41c15) 
libraptorhtml.so + 0x370c9b (0x40cc6c9b) 
libraptorhtml.so + 0x2e8e3f (0x40c3ee3f) 
libraptorhtml.so + 0x2ed8ad (0x40c438ad) 
libraptorhtml.so + 0x2ebd01 (0x40c41d01) 
libraptorhtml.so + 0x3cfb89 (0x40d25b89) 
libraptorhtml.so + 0x1ebd67 (0x40b41d67) 
librdf.so + 0x5e494 (0x4050c494) 
librdf.so + 0x4f538 (0x404fd538) 
librdf.so + 0x4b459 (0x404f9459) 
libjsdom.so + 0x54391 (0x403e7391) 
libmozjs.so + 0x28a5f (0x4010aa5f) 
libmozjs.so + 0x2f362 (0x40111362) 
libmozjs.so + 0x28aaa (0x4010aaaa) 
libmozjs.so + 0x28c8c (0x4010ac8c) 
libmozjs.so + 0x1082f (0x400f282f) 
libjsdom.so + 0x2dbbe (0x403c0bbe) 
libjsdom.so + 0x5b756 (0x403ee756) 
libraptorhtml.so + 0x38b890 (0x40ce1890) 
libraptorhtml.so + 0x38ae43 (0x40ce0e43) 
libraptorhtml.so + 0x1af710 (0x40b05710) 
librdf.so + 0x4ffbd (0x404fdfbd) 
*** Bug 41622 has been marked as a duplicate of this bug. ***
Updating the summary to include reading message problem.
Summary: Crash at startup during INBOX display → Crash at startup or reading message problem during INBOX display
I didn't see a crash since Jun 3 or so. Still the infinite spin sometimes (but
not that often anymore).

Adjusting SUMMARY. Removing CRASH keyword.
Keywords: crash
Summary: Crash at startup or reading message problem during INBOX display → Reading message problem during INBOX display
By using today's 06-09-08-M17 commercial build. 
Yes. I am still having problem for reading messages from the message body of the 
Inbox. It's not every time but sometimes....
By using today's Linux 06-12-08-M17 commercial build:
Sometimes, I am still seeing this problem.....
Sorry, I was using today's Linux Mozilla build.
This bug is a bit of a mess. Can someone describe the remaining problem(s), if 
any, and try with a recent build? My guess is that the crash had to do with the 
envelope parsing problem I fixed last week. I don't really understand (or ever 
see) the hang reading a message.
M16 has been out for a while now, these bugs target milestones need to be 
updated.
Ben, Karen, anyone still seeing any of the problems described here?
David, I will test soon.
By using 06-21-08-M17 commercial build on UW IMAP mail account:
I got one time reading message problem out of seven times.
I am thinking it's better to confirm with Ben too.
Ben, how about your results?
I didn't have to try long: right the first start of the 2000-06-21-20 Linux
nightly showed the bug. The 3 following starts went fine.
Karen, did you reproduce this on NT or Linux? Ben, I get the impression that you 
open a standalone message window frequently, and that's often when the problem 
manifests itself. Could you get an imap log of that? I'm pretty sure the crash 
log is for a seperate, fixed problem.
David, yes, I nearly always use standalone msg windows. Msg pane is collapsed.
There are plenty of IMAP logs above (all of them with standalone msg windows,
IIRC)!?!
Eh? You lost me. There's only one imap log attached to this bug and it doesn't
show any message loads or anything besides biffs going off.
Ops, yup, not plenty. I know it's not very helpful, but that's all I got :-(. I
don't know, why the relevant actions weren't logged.
David, I just noticed that the log I attached was about the crash. I will try to
give you a log from the infinite spin.
I haven't see this problem for today's Linux 06-30-09-M17 commercial build so 
far.....
removing nsbeta2+ and asking for consideration to cut from beta2.  This doesn't
appear to be easily reproduceable.
Whiteboard: [nsbeta2+]
bienvenu,
there are *no* IMAP log entries related to the (requested) msg load at all. I
watched the IMAP log file during running Mozilla: The first entry written there
after I try to open a msg is

4101[8bc7f48]: smserver:A:SendData: 8 select "Trash"

and appears after I closed Mozilla (I guess, that's "Empty Trash").
OK, thanks, that's pretty odd.  I wonder if we've got a confused connection
cache so that we never think we have a connection free to run the message load.
Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [nsbeta2-]
nsbeta3, correctness keywords assuming Ben still sees ths problem.
Status: NEW → ASSIGNED
Keywords: correctness, nsbeta3
Target Milestone: M16 → M18
Yes, I still do see the problem, but I currently gave up on dogfood.
Keywords: mail2
- per mail triage
Whiteboard: [nsbeta2-] → [nsbeta3-][nsbeta2-]
This means, I have to switch the server in order to use the product :-(. Well,
mabye I should do that anyway.
NO crash anymore - lowering severity to major.
Severity: critical → major
I didn't see this bug for a while (> 1 month) (but I didn't eat much dogfood).
Marking WORKSFORME.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Yes. I didn't see this problem for a while.
Verified on Linux 10-11-09-MN6 build. 
Marking as verified.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: