Offline Syncronize Newsgroups crashes



17 years ago
14 years ago


(Reporter: azverkan, Assigned: Bienvenu)


Windows 2000

Firefox Tracking Flags

(Not tracked)



(1 attachment)



17 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7+) Gecko/20020124

After subscribing to some groups on a news server.  And marking all of them as
Download when Synchronize.  Selecting File/Offline/Download Now and choosing
just Newgroups.  Mozilla will crash every time.

Comment 1

17 years ago
this doesn't crash for me but I'll look into it some more.
Ever confirmed: true

Comment 2

17 years ago
Sorry didn't get to this earlier.
using 2002012503 build on nt 4.0 I was not able to 
crash either. Downloading process didn't quite work
but it did not crash.

steps i did:
1.subscribe to 4 newsgroups
2.clicked on each newsgroup and at least 1 mesg in each newsgrp
3.File|Offline|Download/Sync Now
4.Checked newsgroups checkbox & work offline once download is complete
5.cliced select button and selected newsgroups
6.clicked ok, then ok again

Reporter is this similar to what you did? Do you have any talkback
id's with the crash?

Some notes:
  -you must get the headers of a newsgrp before it can be downloaded
   You can't download a newly subscribed newsgrp, see bug 84061
  -bug 102782 deals with selecting a newsgroup in "items for download
   use" window but instead of using download/sync now window, you click
   offline icon and say yes at the download prompt. This currently
   doesn't work
  -There is bug 87018 that deals with downloading multiple newsgroups
   as it doesn't always work.
  -bug 109232 -if you do a download/sync now, the downloading process
   won't start till you physically start clicking on some of the mesgs
   in the newsgroups


Comment 3

17 years ago
I can reproduce a crash now, but it's only with the fix for 84061 in my tree. I
hope it's the same crash. It has to do with a circular ownership/reference
problem that causes the search session to get deleted twice. (releasing the
search session releases the last reference to something that's holding onto the
search session). 

Comment 4

17 years ago
I think/hope this is fixed as part of fixing bug 84061
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 5

17 years ago
Created attachment 67250 [details]
Crash log

This crash still occurs in Build 2002013009.  Here is the crash log.  Is the
supposed fix in the 0.98 or main trunk?

Comment 6

17 years ago
Ok, I think I've got the process down to reproduce the crash on both Windows 
and Linux.

1) Subscribe to a mail server and a couple of channels (I did 15 channels).
2) Restart Mozilla (Just to be safe that we are looking at the same bug).
3) Launch a mail window.
4) Expand the news server and click on it, wait for it to finish pulling the 
header counts.
5) Click on each newsgroup channel, waiting for the complete list of headers to 
load before moving on to the next one, until all of your headers are up to date.
6) Click back on the news server, so that you have the newserver web page where 
the message list usually is.
7) Select File/Offline/Download Now and make sure just Newsgroups is selected, 
and under the Select all of the channels are marked for download.
8) Pressing ok should result in an instant crash.
9) 10% of the time mine won't die on the first try, but repeating steps 7 & 8 a 
second time ALWAYS results in a crash (Didn't wait for process to finish).
Resolution: FIXED → ---

Comment 7

17 years ago
only the trunk, and only today (1/31) build. Also, your crash log is not useful
- talkback reports are much more useful. And please don't reopen bugs until
you've tried a build that might have the fix in them!

Comment 8

17 years ago
resolving fixed, so QA can try it again with today's build.
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 9

17 years ago
fwiw: I tried 2002013003 commercial trunk build on NT 4.0
I tried following reporter's steps to reproduce in comment 6
and I was unable to crash. After clicking ok, it says
"Downloading Newsgroups for offline Use" but no downloading
is really taking place until I go into the newsgroup and
select a mesg to 'kick start' the download process, similar
to bug 109232.

I will try today's build to see if this is fixed.

Comment 10

17 years ago
Still got this to crash using the build from

There's no talkback in that build though.

Comment 11

17 years ago
*** Bug 122823 has been marked as a duplicate of this bug. ***

Comment 12

17 years ago
unfortunately, the talkback stack trash is not informative - it shows a crash in
setupapi.dll, which isn't involved in downloading newsgroups for offline use :-(
I can get bad things to happen if I get multiple download and syncs running at
the same time, though I can't get the first download to crash (the crash I fixed
had to do with the first download). I'm not sure if both the first time crash
and the multiple downloads crash are both still happening to people. I'll make
it so you can't get two downloads going at the same time (I believe there's
already a bug open for that).

Comment 13

17 years ago
I still get crashes with 2002013103 on Win2k, installed from installer.exe. 
Strangely, no problems occur with the non-installer zipfile, same 

What happened with the installer.exe build:
This happens with a completely new mozilla setup, only one news 
account configured. All old account info deleted. I subscribe to 6 n.p.m. 
newsgroups. First time mozilla crashes when trying to synchronize (just after 
clicking "ok"). Second time it starts downloading the first newsgroup from the 
account. Directly after finishing downloading messages in the first group, Moz 
crashes. Third time sync: no new messages in first group, Moz downloads all 
messages in the second group, crashes after finishing this second group. Fourth 
time sync: Moz downloads third group, crashes after finishing this group. 

When the first newsgroup in my newsaccount receives a new message, Moz tries to 
download that new message first and crashes after finishing this message. After 
a restart, hitting Sync again, it starts again with the next group, and crashes 
again after finishing just one group.

Strangely, this does not happen on my laptop (Win2k, too), it downloads 2 out of 
2 newsgroups without any crash. Could this be related to my desktop computer 
having 2 processors? (all crashes occur on my desktop). Using the zipfile 
instead of the installer.exe Sync works fine again. Strange....

Comment 14

17 years ago
having dual processors can definitely expose some necko/nspr problems, and I
believe there are a lot of reports of general instability on dual processor
systems recently.

Comment 15

17 years ago
1-31-06-trunk win nt 4.0
1-31-08-trunk linux 2.2, mac 9.1

Ok I tried doing a download/sync now on newsgroups
and I am unable to crash on any of the builds.

Reporter 1: Brandon, Following your steps to reproduce
I cannot crash.

Reporter 2:r.p.j, Looks like from David's comment prob with dual processors?

Comment 16

17 years ago
After working fine for some runs, I just discovered a setting that leads to Moz 
crashing when syncing newsgroups:

Mail & Newsgroups account settings --> Offline & Disk Space --> 

When I check "Download only unread message bodies" and "Only keep unread 
messages" and "keep messages from the last 30 days" Moz continually crashes 
after finishing downloading all messages in a newsgroup. After deselecting the 
mentioned options, it keeps crashing after successfully downloading the first 
group with new messages. I can find no way to revert to the original situation.

Again this problem only occurs on my Dual Celeron 366 machine. My P850-laptop 
works fine with the same setup. Talkback-incidents TB2360915Z, TB2360800K, 
TB2360409K, TB2360379Y, TB2360352Q, TB2360212G, TB2360087X. Probably this will 
help finding a cause?

This problem has been occuring for some months already, I believe it has little 
to do with recent code changes.

Comment 17

17 years ago
I rebooted my linux box to a non-smp kernel and I cannot reproduce the crash.

Whats the bug to follow for the SMP general instability stuff?


17 years ago
Resolution: FIXED → ---

Comment 18

17 years ago
This is the main stack trace I can find from those talkback id's. My rough guess
is that there's some sort of race condition removing timer events from the event
queue. Downloading newsgroups for offline use uses msg search to find the
articles we need to download, and msg search uses timers to do time slicing. I
don't know why this is only happening on multiple-cpu machines. I'll look again
at the timer handling code in search, but I'm cc'ing some people who either know
how these event queues work or might know if the reported general instability on
dual-cpu machines could be related to this problem.

destroyMyEvent [d:\builds\seamonkey\mozilla\xpcom\threads\nsTimerImpl.cpp, line 294]
PL_DestroyEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 628]
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 603]
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 524]
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 308]
main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1301]
main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1628]

Comment 19

17 years ago
cc'ing some event queue and timer people

Comment 20

17 years ago
You might want to check out bug 118004, it looks similar.

Comment 21

17 years ago
Adding to my report of a crash when synchronizing newsgroups for offline use on 
a dual CPU machine: since I downloaded 0.9.9 the problem has disappeared, Moz 
doesn't crash anymore when starting downloading messages for the second 
selected group.
Very cool, forces me to get rid of NN 4.79 :-)

Comment 22

17 years ago
great, that confirms it's a dup of bug 118004

*** This bug has been marked as a duplicate of 118004 ***
Last Resolved: 17 years ago17 years ago
Resolution: --- → DUPLICATE
verified dup
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.