Closed Bug 69231 Opened 24 years ago Closed 23 years ago

subscribe crashes when server sends "..."

Categories

(SeaMonkey :: MailNews: Message Display, defect, P2)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: shochat, Assigned: sspitzer)

Details

(Keywords: crash, Whiteboard: [nsbeta1+])

Attachments

(3 files)

Ok, here it is.
571 bytes, patch
Details | Diff | Splinter Review
This is a better patch. Explanation to follow.
1.19 KB, patch
Details | Diff | Splinter Review
patch, please test on your server.
3.27 KB, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.1 i686; en-US; 0.7) Gecko/20010105
BuildID:    2001021503 and 0000000000 (CVS 2001-02-17)

Regression in 0.8 (problem not present in 0.7). When attempting to subscribe to
newsgroups for a new news account, the subscribe dialog
appears and a second later, mozilla crashes. This occurs with 0.8 binary and
with CVS from 2001-02-17. It also occurs with a freshly
created profile. For the CVS version, the following message accompanies the problem:
###!!! ASSERTION: didn't find the node: 'node', file nsSubscribableServer.cpp,
line 199
###!!! Break: at file nsSubscribableServer.cpp, line 199
###!!! ASSERTION: failed to add to subscribe ds: 'NS_SUCCEEDED(rv)', file
nsNNTPProtocol.cpp, line 3274
###!!! Break: at file nsNNTPProtocol.cpp, line 3274


Reproducible: Always
Steps to Reproduce:
1.Delete or rename ~/.mozilla
2.Start mozilla
3.Use the account wizard to set up the news account.
4.With the account selected, invoke File->Subscribe.


Actual Results:  The subscribe dialog appears and a short time later (before any
newsgroups have appeared), mozilla terminates.


Expected Results:  Produced a list of newsgroups available on the selected server.
Reporter, are you sure you did a full rebuild (a.k.a clobber)?
Severity: major → critical
Keywords: crash
QA Contact: esther → stephend
Håkan,
If you mean force everything to recompile, the answer is yes. In this case, 
I had deleted my entire tree, downloaded a new tarball, sync'd with CVS and
rebuilt. So in this case, everything recomplied from scratch. I guess I could 
have used 'clean' or 'everything', but I wanted a total fresh start.

Did you subscribe using the context menu or by using the File | Subscribe menu?
I think Navin gets this.  Re-assigning.
Assignee: sspitzer → naving
I had always used File | Subscribe. After seeing comment from stephend, I
tried the context menu. Same result (crash).

Reporter, if you try with this build and a new profile, do you still crash?

ftp://ftp.mozilla.org/pub/mozilla/nightly/2001-02-18-06-Mtrunk/mozilla-i686-pc-linux-gnu-sea.tar.gz

Thanks for reporting bugs and using Mozilla!
Ok, I took that new version and with a new profile (I just rename my fully-
populated .mozilla so it will make a new one), I set up a new news "account" and
when I tried to subscribe, it crashed, but after a longer delay (20 seconds 
during which the empty subscribe dialog box stayed up). Important: All these
crashes are with the server news.ne.mediaone.net which has a very large list
of groups. I tried setting up news.mozilla.org (tiny list of groups) and the
subscribe dialog worked fine. Maybe it just can't handle very large lists. Or
maybe it is some other incompatability between this particular server and recent
mozilla subscribe code.
Do you have a talkback enabled build?  I'm pretty sure this is a DUP of a
another bug we've got, but I'll need to the stack trace to verify.  Thanks.
Status: UNCONFIRMED → NEW
Ever confirmed: true
How do I create a tallkback-enabled build (for Linux)? I have a CVS setup,
but I only see that option under OS/2 in the Build Configurator. Can I just
set a breakpoint somewhere at the assertion failure and then get a bt from gdb?
Or, would the --enable-crash-on-assert option give me a core dump?
talkback can only be done by a group that has talkback [i can only think of 
netscape.com].  a gdb bt w/ debug info is good enough.
I am not able to reproduce this on today's linux debug build
Here is the stack trace at the point of the SIGSEGV:
#0  chunk_free (ar_ptr=0x4044ed60, p=0x8e3bef9) at malloc.c:3049
#1  0x403b9fba in __libc_free (mem=0x8e3bf01) at malloc.c:3023
#2  0x402b4a65 in PR_Free (ptr=0x8e3bf01) at prmem.c:66
#3  0x420faafc in nsNNTPProtocol::ReadNewsList (this=0x8dce610,
inputStream=0x8e44928, length=8082) at nsNNTPProtocol.cpp:3301
#4  0x42101e37 in nsNNTPProtocol::ProcessProtocolState (this=0x8dce610,
url=0x8dce324, inputStream=0x8e44928, sourceOffset=110, length=8082) at
nsNNTPProtocol.cpp:5097
#5  0x42063721 in nsMsgProtocol::OnDataAvailable (this=0x8dce618,
ctxt=0x8dce320, inStr=0x8e44928, sourceOffset=110, count=8082) at
nsMsgProtocol.cpp:194
#6  0x40de8a44 in nsOnDataAvailableEvent::HandleEvent (this=0x41f06900) at
nsStreamListenerProxy.cpp:160
#7  0x40de78c0 in nsStreamObserverEvent::HandlePLEvent (aEvent=0x41f06900) at
nsStreamObserverProxy.cpp:77
#8  0x4013308e in PL_HandleEvent (self=0x41f06900) at plevent.c:576
#9  0x40132eac in PL_ProcessPendingEvents (self=0x8cef450) at plevent.c:509
#10 0x40134dd9 in nsEventQueueImpl::ProcessPendingEvents (this=0x8d03ed8) at
nsEventQueue.cpp:361
#11 0x407c7784 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
#12 0x407c73bf in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
#13 0x4098faca in ?? () from /usr/lib/libglib-1.2.so.0
#14 0x40991186 in ?? () from /usr/lib/libglib-1.2.so.0
#15 0x40991751 in ?? () from /usr/lib/libglib-1.2.so.0
#16 0x40991804 in ?? () from /usr/lib/libglib-1.2.so.0
#17 0x407c7f27 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
#18 0x407424c7 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libnsappshell.so
#19 0x4074e51e in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libnsappshell.so
#20 0x4073e4b9 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libnsappshell.so
#21 0x4055ee06 in ?? () from /usr/local/mozilla/mozilla/dist/bin/libjsdom.so
#22 0x40558a21 in ?? () from /usr/local/mozilla/mozilla/dist/bin/libjsdom.so
#23 0x40546cee in ?? () from /usr/local/mozilla/mozilla/dist/bin/libjsdom.so
#24 0x40200f24 in js_Invoke (cx=0x88522b0, argc=4, flags=0) at jsinterp.c:777
#25 0x40217a97 in js_Interpret (cx=0x88522b0, result=0xbfffdedc) at jsinterp.c:2670
#26 0x40200f9d in js_Invoke (cx=0x88522b0, argc=1, flags=2) at jsinterp.c:794
#27 0x402012fc in js_InternalInvoke (cx=0x88522b0, obj=0x8d22ac0,
fval=147991416, flags=0, argc=1, argv=0xbfffe190, rval=0xbfffe060) at jsinterp.c:866
#28 0x401ceda7 in JS_CallFunctionValue (cx=0x88522b0, obj=0x8d22ac0,
fval=147991416, argc=1, argv=0xbfffe190, rval=0xbfffe060) at jsapi.c:3268
#29 0x40538dfd in ?? () from /usr/local/mozilla/mozilla/dist/bin/libjsdom.so
#30 0x4059378c in ?? () from /usr/local/mozilla/mozilla/dist/bin/libjsdom.so
#31 0x4135b58c in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgklayout.so
#32 0x4135de05 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgklayout.so
#33 0x40c5554a in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/librdf.so
#34 0x413d51b1 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgklayout.so
#35 0x415f1e7e in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgklayout.so
#36 0x415ed49b in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgklayout.so
#37 0x413d5027 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgklayout.so
#38 0x413d4b2a in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgklayout.so
#39 0x41cfceab in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgkview.so
#40 0x41cfce32 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgkview.so
#41 0x41cfce32 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgkview.so
#42 0x41cfce32 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgkview.so
#43 0x41d106c5 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgkview.so
#44 0x41cfc554 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgkview.so
#45 0x407db948 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
#46 0x407db58c in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
#47 0x407dba00 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
#48 0x407dcd35 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
#49 0x407e3310 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
#50 0x407d323d in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
#51 0x407d2ee9 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
#52 0x4096453b in ?? () from /usr/lib/libgdk-1.2.so.0
#53 0x40991186 in ?? () from /usr/lib/libglib-1.2.so.0
#54 0x40991751 in ?? () from /usr/lib/libglib-1.2.so.0
#55 0x409918f1 in ?? () from /usr/lib/libglib-1.2.so.0
#56 0x408b98e9 in ?? () from /usr/lib/libgtk-1.2.so.0
#57 0x407c7e7a in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
#58 0x4074a154 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libnsappshell.so
#59 0x8056703 in main1 (argc=1, argv=0xbffff77c, nativeApp=0x0) at
nsAppRunner.cpp:978
#60 0x80573ba in main (argc=1, argv=0xbffff77c) at nsAppRunner.cpp:1270
(gdb) 
I am seeing from the steps to reproduce that you have deleted or renamed 
~/.mozilla where all the profiles are stored. Please see that your 
server directory exists physically
Yes News/news.ne.mediaone.net exists (empty). Also the corresponding newsrc file.
If you delete panacea.dat does it still crash?
Yes, it still crashes, both with the original 0.8 binary and my recent CVS
version. But in the test which I did before where I start out with no
profile at all (forcing mozilla to create a new one) there was of course no
prior panacea.dat. Or did you mean to delete it while mozilla is running,
immediately before the subscribe attempt?


Hmm..I'm having no problems with build 2001022808 using Mandrake 7.2 with KDE.
So, if you rm -r the directory that contains the mozilla binary, and you
download a fresh mozilla-i686-pc-linux-gnu.tar.gz, and then tar -xzvf that file
and ./mozilla, it still crashes?
Yes. I just downloaded nightly binary build (id 2001022821) into an empty
directory. I renamed my ~/.mozilla and launched the _new_ mozilla.
Went to mail/news. Since this was a freshly created profile, I got the "account
wizard" and proceeded to create a news account for news.ne.mediaone.net.
I highlighted the server and used the context menu to invoke subscribe.
It crashed after displaying the subscribe dialog for about one second.

What symbol can I break at (using a debug CVS build) so that I can get a stack
trace at the exact point where the assertion failure occurs? Note that the 
error message from a debug version (see my original comment on 2/17) always
mentions two source line numbers preceded by "Break: at". Does that mean I
should set breakpoints at those 2 places and then invoke the subscribe function?
Is there an environment variable (such as XPCOM_BREAK_ON_LOAD) that 
will make it break on any assertion failure?
Seth, Navin, can you guys help him get a stack trace going? Thanks.  I can't
reproduce this crash, but he's getting it all the time and it would be great to
find out what's causing it.
Ok, I think I finally have a decent stack dump. I had to get a snapshot gdb
in order to escape bug 57051.
Based on the messages I saw when running without gdb I figured I should set
a breakpoint at nsSubscribableServer.cpp:199. When I do that, I get this bt:
#0  nsSubscribableServer::AddTo (this=0x86e56a8, aName=0x8e95fe8
"alt.offroading-uk", addAsSubscribed=0, changeIfExists=1)
    at nsSubscribableServer.cpp:199
#1  0x4209891a in nsNntpIncomingServer::AddTo (this=0x8c0aa68, aName=0x8e95fe8
"alt.offroading-uk", addAsSubscribed=0, 
    changeIfExists=1) at nsNntpIncomingServer.cpp:1114
#2  0x42097ff9 in nsNntpIncomingServer::AddNewsgroupToList (this=0x8c0aa68,
aName=0x8e95fe8 "alt.offroading-uk")
    at nsNntpIncomingServer.cpp:1004
#3  0x420719bc in nsNNTPProtocol::ReadNewsList (this=0x8f42208,
inputStream=0x8f470b8, length=5815)
    at nsNNTPProtocol.cpp:3285
#4  0x42078bd4 in nsNNTPProtocol::ProcessProtocolState (this=0x8f42208,
url=0x8f31adc, inputStream=0x8f470b8, 
    sourceOffset=110, length=5815) at nsNNTPProtocol.cpp:5109
#5  0x4213e39c in nsMsgProtocol::OnDataAvailable (this=0x8f42210,
request=0x8f47190, ctxt=0x8f31ad8, inStr=0x8f470b8, 
    sourceOffset=110, count=5815) at nsMsgProtocol.cpp:218
#6  0x40d12385 in nsOnDataAvailableEvent::HandleEvent (this=0x8eb92f8) at
nsStreamListenerProxy.cpp:161
#7  0x40d10fea in nsStreamObserverEvent::HandlePLEvent (aEvent=0x8eb92f8) at
nsStreamObserverProxy.cpp:78
#8  0x401351c3 in PL_HandleEvent (self=0x8eb92f8) at plevent.c:576
#9  0x40134fb0 in PL_ProcessPendingEvents (self=0x8e2b5e8) at plevent.c:509
#10 0x401371cc in nsEventQueueImpl::ProcessPendingEvents (this=0x8e19c38) at
nsEventQueue.cpp:361
#11 0x407bbe72 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
#12 0x407bba48 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
#13 0x4098daca in ?? () from /usr/lib/libglib-1.2.so.0
#14 0x4098f186 in ?? () from /usr/lib/libglib-1.2.so.0
#15 0x4098f751 in ?? () from /usr/lib/libglib-1.2.so.0
#16 0x4098f804 in ?? () from /usr/lib/libglib-1.2.so.0
#17 0x407bc6ba in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
#18 0x4057ce5a in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libnsappshell.so
#19 0x40589dbf in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libnsappshell.so
#20 0x4057852e in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libnsappshell.so
#21 0x40c28f3d in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libembedcomponents.so
#22 0x40657899 in ?? () from ./libjsdom.so
#23 0x40652caa in ?? () from ./libjsdom.so
#24 0x4063f64c in ?? () from ./libjsdom.so
#25 0x4021a48d in js_Invoke (cx=0x88cdd80, argc=4, flags=0) at jsinterp.c:777
#26 0x40228899 in js_Interpret (cx=0x88cdd80, result=0xbfffde30) at jsinterp.c:2670
#27 0x4021a510 in js_Invoke (cx=0x88cdd80, argc=1, flags=2) at jsinterp.c:794
#28 0x4021a83f in js_InternalInvoke (cx=0x88cdd80, obj=0x8b6f070,
fval=146207008, flags=0, argc=1, argv=0xbfffe124, 
    rval=0xbfffdfe8) at jsinterp.c:866
#29 0x401ee7c8 in JS_CallFunctionValue (cx=0x88cdd80, obj=0x8b6f070,
fval=146207008, argc=1, argv=0xbfffe124, 
    rval=0xbfffdfe8) at jsapi.c:3268
#30 0x40630e61 in ?? () from ./libjsdom.so
#31 0x4068e55a in ?? () from ./libjsdom.so
#32 0x4122ab91 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgkcontent.so
#33 0x4122d598 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgkcontent.so
#34 0x4138da03 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgkcontent.so
#35 0x41c51705 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgklayout.so
#36 0x41d6c14a in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgklayout.so
#37 0x41d6741e in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgklayout.so
#38 0x41c51550 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgklayout.so
#39 0x41c50fef in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgklayout.so
#40 0x41ebb98e in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgkview.so
#41 0x41ebb91e in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgkview.so
#42 0x41ebb91e in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgkview.so
#43 0x41ebb91e in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgkview.so
#44 0x41ed03d2 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgkview.so
#45 0x41ebaf60 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libgkview.so
#46 0x407d22ab in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
#47 0x407d1e86 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
---Type <return> to continue, or q <return> to quit---
#48 0x407d236b in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
#49 0x407d37e5 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
#50 0x407da763 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
#51 0x407c8af0 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
#52 0x407c872c in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
#53 0x4096253b in ?? () from /usr/lib/libgdk-1.2.so.0
#54 0x4098f186 in ?? () from /usr/lib/libglib-1.2.so.0
#55 0x4098f751 in ?? () from /usr/lib/libglib-1.2.so.0
#56 0x4098f8f1 in ?? () from /usr/lib/libglib-1.2.so.0
#57 0x408b78e9 in ?? () from /usr/lib/libgtk-1.2.so.0
#58 0x407bc60d in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libwidget_gtk.so
#59 0x405853a5 in ?? () from
/usr/local/mozilla/mozilla/dist/bin/components/libnsappshell.so
#60 0x08057356 in main1 (argc=1, argv=0xbffff8cc, nativeApp=0x0) at
nsAppRunner.cpp:1004
#61 0x08058191 in main (argc=1, argv=0xbffff8cc) at nsAppRunner.cpp:1295
#62 0x403429cb in __libc_start_main (main=0x8057f7c <main>, argc=1,
argv=0xbffff8cc, init=0x8051948 <_init>, 
    fini=0x8067ed0 <_fini>, rtld_fini=0x4000ae60 <_dl_fini>,
stack_end=0xbffff8c4) at ../sysdeps/generic/libc-start.c:92

The code around 199 is:
192
    SubscribeTreeNode *node = nsnull;
193

194
    // todo, shouldn't we pass in addAsSubscribed, for the 
195
    // default value if we create it?
196
    rv = FindAndCreateNode(aName, &node);
197
    NS_ENSURE_SUCCESS(rv,rv);
198

199
    NS_ASSERTION(node,"didn't find the node");
200
    if (!node) return NS_ERROR_FAILURE;
201


I believe that assertion is what eventually fails, but not right away. With the
breakpoint still set, I do 'c' many times and keep hitting line
199, each time with a different newsgroup. Then after much of this, we finally
get:

Breakpoint 2, nsSubscribableServer::AddTo (this=0x86e56a8, aName=0x8ed4658
"alt.aus.telehealth", addAsSubscribed=0, 
    changeIfExists=1) at nsSubscribableServer.cpp:199
199
    NS_ASSERTION(node,"didn't find the node");
(gdb) c
Continuing.

Breakpoint 2, nsSubscribableServer::AddTo (this=0x86e56a8, aName=0x8ed4658
"alt.telehealth.test", addAsSubscribed=0, 
    changeIfExists=1) at nsSubscribableServer.cpp:199
199
    NS_ASSERTION(node,"didn't find the node");
(gdb) c
Continuing.

Breakpoint 2, nsSubscribableServer::AddTo (this=0x86e56a8, aName=0x8ed3559 "..",
addAsSubscribed=0, changeIfExists=1)
    at nsSubscribableServer.cpp:199
199
    NS_ASSERTION(node,"didn't find the node");
(gdb) c
Continuing.
c###!!! ASSERTION: didn't find the node: 'node', file nsSubscribableServer.cpp,
line 199
###!!! Break: at file nsSubscribableServer.cpp, line 199
###!!! ASSERTION: failed to add to subscribe ds: 'NS_SUCCEEDED(rv)', file
nsNNTPProtocol.cpp, line 3286
###!!! Break: at file nsNNTPProtocol.cpp, line 3286

c
Program received signal SIGSEGV, Segmentation fault.
chunk_free (ar_ptr=0x40418d60, p=0x8ed3551) at malloc.c:3049

Could it be that funny newsgroup name of ".." that is killing us?

I hope this helps. Let me know if I should set a different breakpoint.
This was done on a CVS co on 3/3 at about 21:30 EST.

nominating for nsbeta1, if there is some strange config or something and we find
it, it would be great to fix this, but I still can't reproduce on linux (mac I
can, known bug.)
Keywords: nsbeta1
I have found a fix for this problem. It turns out that when dealing with my
ISP's news server (AT&T Broadband for Eastern Mass) news.ne.mediaone.net,
in the routine nsNNTPProtocol::ReadNewsList(), the call at line 3190:
(all line numbers are for revision 1.244 of nsNNTPProtocol.cpp)

line = m_lineStreamBuffer->ReadNextLine(inputStream, status, pauseForMoreData);

eventually returns a pointer to this string (sometimes only happens after
many calls):
... 0000000001 0000000002 y

Then at line 3214-6, line is incremented past the 1st '.'.
At line 3283, a null is put in place of the 1st blank and we are left with 
just "..".
As I reported before, the call at line 3293:
 rv = m_nntpServer->AddNewsgroupToList(line);
fails and results in an assertion failure. However, this is not the crash.
The segfault comes from line 3321: PR_FREEIF(line);

My "fix" is to check back at line 3192 to see if line begins
with "..". If so, I return immediately, bypassing the fatal PR_FREEIF(line).

I do not believe that this is the correct final fix. But I hope it is enough
information to help someone more familiar with the code to see what the 
real problem is. Trying to free line after incrementing it seems fishy to me,
but I have a pretty limited understanding of the design at this point.

Do you have CVS?  If you could produce a diff -u out of this, that would be
excellent.
Attached patch Ok, here it is. — — Splinter Review 

    
    

    
  
marking nsbeta1+ and moving to mozilla0.9

Can we try out shocat's patch (thanks for the patch)?  If it works we might try
to get this into 0.8.1
Priority: -- → P2
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.9

    
    

    
  
hold off on this, I'm returning to the trunk.

the "." worries me, I hope we're not escaping the periods when we aren't
supposed to.

naving, can I take this back from you?

    
    

    
  
the fact that we are crashing in PR_FREEIF() is not a good sign.

reporter, can you use 4.x and then email me your 4.x hostinfo.dat file for this
server?  (you won't be able to attach it to bugzilla, it should be pretty big. 
probably a couple megs when compressed.)

I can use that to reproduce this crasher.

    
    

    
  
I have now found through testing that the reason for the crash was indeed the
fact that line was passed to PR_FREEIF() *after* being incremented (to bypass
the initial period). When I made a change consisting only of saving the original
value of line in line_orig and passing that instead of line to PR_FREEIF() at
the end of the routine, there was no crash. However, I still got the assertion
failure since again, ".." was being passed to 
m_nntpServer->AddNewsgroupToList(). The assertion failure terminates processing
of the newsgroup list before it is completely populated. So in the above patch,
I additionally check for a third period, given that there are two. That means
we have the pathologically strange line from news.ne.mediaone.net. In this case
we return as in the previous patch. The reason this solution is better is that
the original logic is preserved for handling a potential server that sends a
legitimate line starting with a "data" period preceded by an escaping period 
(news.ne.mediaone.net does not ever do that). In particular, it will not crash
since the original value  of line is still passed to PR_FREEIF().

    
    

    
  
Seth, you can take it back. I never started to work on this one.

    
    

    
  
I am not able to reproduce this on my linux debug build from today. 
Marking worksforme. Reopen, if you see the problem
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME

    
    

    
  
It still crashes using a debug build which I did today at about 7PM EST.
Please read my comments from 3/13 and 3/14. What I described there still applies
since nsNNTPProtocol.cpp is still at revision 1.244. The problem is caused by
the server sending a line in the newsgroup list starting with 2 or more periods
(3 in my case). This results in the variable 'line' being incremented. And then
the crash is caused by a segfault resulting from trying to free this incremented
pointer. To reproduce the crash, you need to be using a news server which gives
you the strange line with the periods among the valid newsgroup names. 
Evidenty mine does that (news.ne.mediaone.net) but yours does not. Also, as I 
said on 2/19, it works fine for me too as long as I use a different news
server such as news.mozilla.org. Either of the two patches I posted actually
does fix this, but neither has been applied.



    
    

    
  
Suggesting we re-open this and have Seth take a further look at this (since he
had previous comments regarding the patches.)
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

    
    

    
  
I am not able to subscribe to news.ne.mediaone.net. It throws an alert.
" A News (NNTP) error occurred : Permission denied ......"

Do you have a test account that I can use. 



    
    

    
  
the crasher that shochat found is still valid, I just haven't gotten to his 
patches yet.

naving, feel free to re-assign to me.


    
    

    
  
shocat@acm.org, I need a test account to verify your patch...

    
    

    
  
reporter, does 4.x crash when try the same thing?

naving, we can duplicate this in house (by trickery).

    
    

    
  
Seth, how ?

    
  
Assignee: naving → sspitzer
Status: REOPENED → NEW

    
    

    
  
reassign to sspitzer

    
    

    
  
Moving to 0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1

    
    

    
  
I know the target is now set to 0.9.1, but since people have trouble testing
this, I thought I would report that the crash is still there in 0.9. Is there a
disagreement with the analysis and fix which I provided?



    
    

    
  
schochat:  I haven't had the cycles to test / review your patch yet.

I'll work on this today.
Status: NEW → ASSIGNED

    
    

    
  
Ok, just don't use the first one I posted. Although it worked, it clearly has
a memory leak since it never frees 'line' at all if the funny line from the
server is detected.

    
    

    
  
shochat, your fix makes sense.

I looked at the 4.x code, and the reason it didn't crash is we didn't copy the 
buffer, so we didn't have to free it.  (note, perhaps we can investigate what 
it would take to get rid of that extra buffer copy)

I've got a fixed based closely on your fix.  coming soon...

    
    

    
  
shochat@acm.org, can you review and test that patch?

    
    

    
  
Absolutely. I should be able to do it tonight.

    
    

    
  
updating summary.
Summary: subscribe crashes immediately in 0.8 → subscribe crashes when server sends "..."

    
    

    
  
I made sure I had an unmodified version 1.262 of nsNNTPProtocol.cpp 
(using cvs status).
But when I try to apply the patch, I get:
$ patch -p0 < /usr/local/mozilla/news_5_9.patch
patching file `nsNNTPProtocol.cpp'
Hunk #1 FAILED at 3129.
Hunk #2 FAILED at 3155.
Hunk #3 FAILED at 3218.
Hunk #4 FAILED at 3257.
4 out of 4 hunks FAILED -- saving rejects to nsNNTPProtocol.cpp.rej

What am I doing wrong?


    
    

    
  
probably line endings.  my patch comes from winnt, you are on linux, right?

to convert line endings, use dos2unix


    
    

    
  
Ok, that worked (don't have dos2unix, used emacs). Trouble is my latest CVS
build of c/o date 8 May 2001 20:06:12 won't even start:
###!!! ASSERTION: bad state!: 'GetResolveState() == PARTIALLY_RESOLVED', file
xptiInterfaceInfo.cpp, line 144
###!!! Break: at file xptiInterfaceInfo.cpp, line 144

So I'm pulling more or less current CVS and will try that. Anyway, getting closer.


    
    

    
  
thanks for keeping me posted.

    
    

    
  
Fix works. No more crash, and the newsgroup list loaded.


    
    

    
  
excellent! 

I'll land the fix (based on your patch) tonight.



    
    

    
  
fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
There isn't a way to reproduce this in-house (QA side) correct?  Is it safe to
verify based on David's comments per it working for him now?

    
    

    
  
I have checked again that retrieving the newsgroup list
(from news.ne.mediaone.net) works properly now (using v. 1.263 of
nsNNTPProtocol.cpp).
Attempting the same operation with 0.9 still causes a crash.

Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey

    
  
Component: MailNews: Subscribe → MailNews: Message Display
QA Contact: stephend → search

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: