53002 - Unknown error when FTP login fails

Status: VERIFIED DUPLICATE of bug 54559

(Core Graveyard :: Networking: FTP, defect, P3)

Description

[Matthew Cline]

With build 20000915 on Linux, I can sometimes download one file of
unknown type just fine, but the second time it gives the error message
"Unknown error [1 804B0015]"; but sometimes I can't even download it
once. (I was downloading
RPMs from http://www.rpmfind.net/)
dialog.

Also, after I get the first "Unknown error [1 80520012" message,
simply left-clicking on the link does nothing. However, right clicking
and selecting "Save link as..." does what I'd expect it do (even
though I still keep getting the unknown error message).

This might be simmilar in some way to bug 52875, which gives "unknown
error [1 80520012]" in different circumstances.

Comment 1

[Matthew Cline]

OK, I've tracked this down to being an FTP login error.

In nsFtpConnectionThread::Process() in nsFtpConnectionThread.cpp, for
case FTP_R_USER, mInternalError is set to NS_ERROR_FTP_LOGIN (defined in
ftpCore.h); it propogates from there.  Don't know what's causing there error,
nor do I know why this is being reported as an unknown error rather than as,
say, "FTP login error".

I'm not sure if this should be reasigned to Networking or not.  It might
be that the networking code is behaving correctly, and it's the error reporting
code that's buggy.  Actually, there's definitly something wrong with the error
reporting code; maybe this should be two bugs?  Dunno.  I'm looking into this
further.

Comment 2

[Asa Dotzler [:asa]]

over to Networking while you investigate.

Comment 3

[Matthew Cline]

The unknown error report occurs when Mozilla recieves response code 530
from the FTP server; this would appear to mean "Not logged in".  So it
would appear that this isn't a bug in the networking code, but somewhere else.

However, the networking code doesn't distinguish between any of the 5XX
reply codes, nor any of the 4XX reply codes, both of which indicate some
sort of error.  If we're going to be giving the user useful error codes,
it would be useful to extract some extra information from the response code.
Hmmmmm.  This might be worth an extra (low priority) bug.

NOTE: I'm changing the summary to reflect this new info.

Comment 4

[Matthew Cline]

Some maybe-useful info on the FTP protocol can be found at these RFCs:

http://www.faqs.org/rfcs/rfc542.html
http://www.faqs.org/rfcs/rfc640.html

Comment 5

[Asa Dotzler [:asa]]

hmm, I thought I moved this to networking.  trying again.

Comment 6

[Gagan]

->rjc

Comment 7

[Matthew Cline]

Moving back to Browser-General, since the FTP/networking code seems to be just
fine.

I'm including some GDB stack traces; the line numbers won't be exact, because
of added debugging statements.

Trace of where nsFtpConnectionThread transfers its internal error code over to
the status code in the AsyncStreamListener:

#0 nsOnStopRequestEvent::Init (this=0x8fefd38, aStatus=2152398869,
aStatusArg=0x0) at nsAsyncStreamListener.cpp:277
#1 0x2b228d74 in nsAsyncStreamObserver::OnStopRequest (this=0x90426f0,
channel=0x904af50, context=0x0, aStatus=2152398869, aStatusArg=0x0)
at nsAsyncStreamListener.cpp:324
#2 0x2b2bca11 in nsAsyncStreamListener::OnStopRequest (this=0x90426f0,
channel=0x904af50, context=0x0, aStatus=2152398869, aStatusArg=0x0)
at nsAsyncStreamListener.h:78
#3 0x2ce9c183 in nsFtpConnectionThread::StopProcessing (this=0x8f86d38)
at nsFtpConnectionThread.cpp:1894
#4 0x2ce9508e in nsFtpConnectionThread::Process (this=0x8f86d38)
at nsFtpConnectionThread.cpp:302
#5 0x2ce9a80c in nsFtpConnectionThread::Run (this=0x8f86d38)
at nsFtpConnectionThread.cpp:1581
#6 0x2abdbe6c in nsThreadPoolRunnable::Run (this=0x8fc2c40)
at nsThread.cpp:689
#7 0x2abd9a7d in nsThread::Main (arg=0x8f417e0) at nsThread.cpp:84
#8 0x2ad59e42 in _pt_root (arg=0x8fdf008) at ptthread.c:198
#9 0x2ad6ecda in pthread_start_thread (arg=0x7edffe7c) at manager.c:214


The stack trace where the AsyncStreamListener pops up the "Unknown Error"
dialog:

#0 nsCommonDialogs::Alert (this=0x919c5b8, inParent=0x0,
inWindowTitle=0x7fffdb5c, inMsg=0x2c855db6) at nsCommonDialogs.cpp:51
#1 0x2c855df2 in nsSingleSignOnPrompt::Alert (this=0x919c6b8,
dialogTitle=0x0, text=0x7fffdb5c) at nsWalletService.cpp:430
#2 0x2b00558c in GlobalWindowImpl::Alert (this=0x90cc608, cx=0x8166a10,
argv=0x92f3ed4, argc=1) at nsGlobalWindow.cpp:1451
#3 0x2aff37e6 in WindowInternalAlert (cx=0x8166a10, obj=0x8744cc8, argc=1,
argv=0x92f3ed4, rval=0x7fffdd04) at nsJSWindow.cpp:2926
#4 0x2aca0a5d in js_Invoke (cx=0x8166a10, argc=1, flags=0) at jsinterp.c:823
#5 0x2acad609 in js_Interpret (cx=0x8166a10, result=0x7fffe6f0)
at jsinterp.c:2624
#6 0x2aca0ae0 in js_Invoke (cx=0x8166a10, argc=3, flags=2) at jsinterp.c:840
#7 0x2ba8579c in nsXPCWrappedJSClass::CallMethod (this=0x90b5290,
wrapper=0x92a3790, methodIndex=3, info=0x891bfd8, nativeParams=0x7fffeb8c)
at xpcwrappedjsclass.cpp:776
#8 0x2ba8356b in nsXPCWrappedJS::CallMethod (this=0x92a3790, methodIndex=3,
info=0x891bfd8, params=0x7fffeb8c) at xpcwrappedjs.cpp:318
#9 0x2abf5a15 in PrepareAndDispatch (self=0x92a3790, methodIndex=3,
args=0x7fffec54) at xptcstubs_unixish_x86.cpp:80
#10 0x2abf5ac5 in nsXPTCStubBase::Stub3 (this=0x92a3790)
at ../../../../../../dist/include/xptcstubsdef.inc:5
#11 0x2ce9f84e in nsStreamXferOp::OnError (this=0x9041220, operation=1,
errorCode=2152398869) at nsStreamXferOp.cpp:147
#12 0x2cea06bd in nsStreamXferOp::OnStopRequest (this=0x9041220,
channel=0x91be9a0, aContext=0x0, aStatus=2152398869, aMsg=0x2ac36250)
at nsStreamXferOp.cpp:437
#13 0x2ce52403 in nsFTPChannel::OnStopRequest (this=0x91be9a0,
aChannel=0x91be9a0, aContext=0x0, aStatus=2152398869,
aStatusArg=0x2ac36250) at nsFTPChannel.cpp:675
#14 0x2b761c95 in nsOnStopRequestEvent::HandleEvent (this=0x2cb1a748)
at nsAsyncStreamListener.cpp:301
#15 0x2b7611a5 in nsStreamListenerEvent::HandlePLEvent (aEvent=0x2cb1d868)
at nsAsyncStreamListener.cpp:97
#16 0x2abd5ba1 in PL_HandleEvent (self=0x2cb1d868) at plevent.c:575
#17 0x2abd5990 in PL_ProcessPendingEvents (self=0x80ab4e8) at plevent.c:508
#18 0x2abd7a0e in nsEventQueueImpl::ProcessPendingEvents (this=0x80ab4c0)
at nsEventQueue.cpp:356
#19 0x2b1efaab in event_processor_callback (data=0x80ab4c0, source=8,
condition=GDK_INPUT_READ) at nsAppShell.cpp:158
#20 0x2b1ef695 in our_gdk_io_invoke (source=0x80cf108, condition=G_IO_IN,
data=0x80cf0f8) at nsAppShell.cpp:58
#21 0x2b3cd8da in g_io_unix_dispatch ()
at ../../../dist/include/nsIPageSequenceFrame.h:112
#22 0x2b3cef96 in g_main_dispatch ()
at ../../../dist/include/nsIPageSequenceFrame.h:112
#23 0x2b3cf561 in g_main_iterate ()
at ../../../dist/include/nsIPageSequenceFrame.h:112
#24 0x2b3cf701 in g_main_run ()
at ../../../dist/include/nsIPageSequenceFrame.h:112
#25 0x2b2f0fdc in gtk_main ()
at ../../../dist/include/nsIPageSequenceFrame.h:112
#26 0x2b1f022a in nsAppShell::Run (this=0x80fe0a0) at nsAppShell.cpp:335
#27 0x2b4f781e in nsAppShellService::Run (this=0x80f7cb8)
at nsAppShellService.cpp:378
#28 0x8055aae in main1 (argc=1, argv=0x7ffff494, nativeApp=0x0)
at nsAppRunner.cpp:958
#29 0x8056221 in main (argc=1, argv=0x7ffff494) at nsAppRunner.cpp:1139

Comment 8

[Gagan]

ftp bugs to component:ftp

Comment 9

[Doug Turner (:dougt)]

Matthew Cline, could you verify that this now works correctly (eg you can
download multiple files without any problem).

Comment 10

[Matthew Cline]

I can't seem to get the 530 FTP error code from the rpmfind FTP server,
so I can't duplicate the conditions; sorry.

But if you're wondering if repeated downloads from rpmfind work now,
*that* works just fine; I don't get any sort of error message from that,
unknown or otherwise.

Maybe we should add QAWANTED?

Comment 11

[Reinout van Schouwen]

I think this is the same bug as bug #54559. Please also see my comments to that one.

Comment 12

[Doug Turner (:dougt)]

This is fixed, but it is also a dup of 54559

*** This bug has been marked as a duplicate of 54559 ***

Comment 13

[Chad Austin]

verified dups