Closed Bug 121532 Opened 23 years ago Closed 22 years ago

hangs during ftp download

Categories

(Core Graveyard :: Networking: FTP, defect)

Product:
Core Graveyard
Component:
Networking: FTP
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: kitty, Assigned: neeti)

References

(
URL
)

Details

Attachments

(5 files)

First connect to ftp.openbsd.org then to ftp.fh-wolfenbuettel.de
8.15 KB, text/plain
Details
Connection log for ftp://ftp.fh-wolfenbuettel.de/pub/os/openbsd
863 bytes, text/plain
Details
Connection log for ftp://ftp.de.openbsd.org/unix/OpenBSD
1.48 KB, text/plain
Details
Connection log for ftp://ftp.leo.org/pub/OpenBSD
886 bytes, text/plain
Details
gdb backtrace of hung Mozilla
5.20 KB, text/plain
Details 
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.17-ll i686)
BuildID:    2002012108

Mozilla hangs while trying to download the above mentioned URL. The CPU usage
pegs to 100% and the program stops responding. I compiled Mozilla using the
source tarball. I also noticed that the downloads fail intermittently. By
failing, I mean that Mozilla downloads complete but the files are less than the
requested size. Usually the above hang is followed by such a failed download.
The hang happens after Mozilla has almost downloaded the file i.e more than 95%.

Reproducible: Sometimes
Steps to Reproduce:
1. Try to download the above URL using Mozilla using Shift+ LeftClick.
2. 
3.

Actual Results:  Mozilla fails to download file completely and hangs on
subsequent attempts to start the download again.

Expected Results:  Mozilla download file completely without error.

I compiled Mozilla using the following options using gcc-2.96-98 from RedHat
7.2.

./configure --prefix=/usr --enable-optimize="-O3 -march=i686" 
            --disable-debug --with-default-mozilla-five-home=/usr/lib/mozilla 
        --enable-strip-libs --disable-tests --disable-short-wchar 
        --enable-nspr-autoconf --with-pthreads --disable-jsd --disable-bidi
--disable-xprint --enable-crypto --enable-xpcom-lea 
        --disable-dtd-debug --disable-logging --disable-logrefcnt 
        --disable-detect-webshell-leaks --disable-xpctools 
        --disable-reflow-perf --disable-perf-metrics --disable-jprof
        --without-profile-modules --disable-verbose-config-defs
        --enable-elf-dynstr-gc --with-system-jpeg --with-system-zlib
        --with-system-png --with-system-mng --enable-mathml 
        --disable-mailnews --disable-ldap


I attached gdb to the hung Mozilla process and got the following trace:

0x40249e3c in pthread_self () at pthread.c:698
698     pthread.c: No such file or directory.
        in pthread.c
kitty> bt
#0  0x40249e3c in pthread_self () at pthread.c:698
#1  0x4022e8dc in PR_EnterMonitor () from /usr/lib/libnspr4.so
#2  0x4018f227 in nsPipe::nsPipeInputStream::ReadSegments () from
/usr/lib/libxpcom.so
#3  0x4019011e in nsPipe::nsPipeInputStream::Read () from /usr/lib/libxpcom.so
#4  0x4018c99c in nsInputStreamTee::Read () from /usr/lib/libxpcom.so
#5  0x40da1393 in NSGetModule () from
/usr/lib/mozilla/components/liburiloader.so
#6  0x40d991cf in NSGetModule () from
/usr/lib/mozilla/components/liburiloader.so
#7  0x4087ba2c in NSGetModule () from /usr/lib/mozilla/components/libnecko.so
#8  0x408b275e in NSGetModule () from /usr/lib/mozilla/components/libnecko.so
#9  0x4087b01d in NSGetModule () from /usr/lib/mozilla/components/libnecko.so
#10 0x4086bf77 in NSGetModule () from /usr/lib/mozilla/components/libnecko.so
#11 0x401a9702 in PL_HandleEvent () from /usr/lib/libxpcom.so
#12 0x401a8b67 in PL_ProcessPendingEvents () from /usr/lib/libxpcom.so
#13 0x401aa2ad in nsEventQueueImpl::ProcessPendingEvents () from
/usr/lib/libxpcom.so
#14 0x40758c36 in NSGetModule () from
/usr/lib/mozilla/components/libwidget_gtk.so
#15 0x407589e1 in NSGetModule () from
/usr/lib/mozilla/components/libwidget_gtk.so
#16 0x403d1f9e in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0
#17 0x403d3773 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#18 0x403d3d39 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#19 0x403d3eec in g_main_run () from /usr/lib/libglib-1.2.so.0
#20 0x402ee333 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#21 0x40758cc9 in NSGetModule () from
/usr/lib/mozilla/components/libwidget_gtk.so
#22 0x40739b62 in NSGetModule () from
/usr/lib/mozilla/components/libnsappshell.so
#23 0x08051c65 in DoCommandLines ()
#24 0x080525db in main ()
#25 0x40519627 in __libc_start_main (main=0x8052440 <main>, argc=1,
ubp_av=0xbffff524, init=0x804c9e8 <_init>, fini=0x8053e70 <_fini>,
rtld_fini=0x4000dcc4 <_dl_fini>, stack_end=0xbffff51c) at
../sysdeps/generic/libc-start.c:129
kitty> quit

Here is a snapshot of top on my machine with shows the Mozilla process hanging.
Pay attention to the netstat process which has become a zombie. I don't know if
Mozilla starts a netstat process. But the zombie disappears if I quit Mozilla. 

97 processes: 90 sleeping, 6 running, 1 zombie, 0 stopped
CPU0 states: 30.0% user,  7.1% system,  0.0% nice, 62.0% idle
CPU1 states: 72.0% user,  0.3% system,  0.0% nice, 26.2% idle
Mem:   515000K av,  495108K used,   19892K free,       0K shrd,   55412K buff
Swap: 1052216K av,   20612K used, 1031604K free                  254784K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
20766 kitty     34   0 44108  43M 15352 R    95.3  8.5   4:53 mozilla-bin
 1469 kitty      6   0  3496 3128  2584 S     9.5  0.6  29:23 gkrellm
21005 kitty      6   0  1176 1176   928 R     1.6  0.2   0:00 top
 1544 kitty      6   0  6564 5992  3504 R     0.9  1.1  22:15 xmms
 1465 kitty      6   0  9008 9008  3056 S     0.6  1.7  17:35 enlightenment
 1388 kitty      6   0  1516 1036  1036 S     0.0  0.2   0:00 bash
 1441 kitty      7   0  1024  856   856 S     0.0  0.1   0:00 startx
 1448 kitty      6   0   668  576   576 S     0.0  0.1   0:00 xinit
 1452 kitty      6   0  1052  892   892 S     0.0  0.1   0:00 .xinitrc
 1464 kitty      6   0   952  852   852 S     0.0  0.1   0:00 ssh-agent
 1545 kitty      6   0  6564 5992  3504 S     0.0  1.1   0:01 xmms
 1546 kitty      6   0  6564 5992  3504 S     0.0  1.1  11:56 xmms
 1547 kitty      6   0  6564 5992  3504 R     0.0  1.1   1:29 xmms
 1569 kitty      6   0  6564 5992  3504 S     0.0  1.1   0:04 xmms
 1645 kitty      6   0  1492 1024  1024 S     0.0  0.1   0:00 bash
 2011 kitty      6   0  1692 1288  1268 S     0.0  0.2   0:00 kdesud
24366 kitty      6   0  2496 2432  1688 S     0.0  0.4   0:08 xscreensaver
17461 kitty      6   0  2548 2548  1420 S     0.0  0.4   0:01 oafd
17469 kitty      6   0  3932 3932  3128 S     0.0  0.7   0:00 bonobo-moniker-
17478 kitty      6   0  4992 4992  4016 S     0.0  0.9   0:00 evolution-alarm
17710 kitty      6   0  6060 6036  4756 S     0.0  1.1   0:00 wombat
18092 kitty      6   0  1352 1352  1144 S     0.0  0.2   0:00 gnome-name-serv
18256 kitty      6   0  4048 4048  1824 S     0.0  0.7   0:00 xterm
18260 kitty      6   0  1520 1520  1108 S     0.0  0.2   0:00 bash
18274 kitty      6   0  2384 2356  1808 S     0.0  0.4   0:00 xterm
18276 kitty     16   0  1480 1480  1084 S     0.0  0.2   0:00 bash
18280 kitty      6   0  2388 2360  1812 S     0.0  0.4   0:00 xterm
18282 kitty     17   0  1480 1480  1084 S     0.0  0.2   0:00 bash
18286 kitty      6   0 26472  25M  5108 S     0.0  5.1   0:56 xemacs
18719 kitty      6   0  8664 8664  4600 R     0.0  1.6   2:29 realplay
18720 kitty     17   0  1680 1680  1640 S     0.0  0.3   0:00 realplay
18721 kitty     17   0  1680 1680  1640 S     0.0  0.3   0:00 realplay
18722 kitty      6   0  8664 8664  4600 S     0.0  1.6   0:00 realplay
18723 kitty     20   0  8664 8664  4600 S     0.0  1.6   0:00 realplay
18784 kitty      6   0  3208 3208  1832 S     0.0  0.6   0:01 xterm
18788 kitty      6   0  1600 1600  1112 S     0.0  0.3   0:00 bash
20837 kitty     12   0     0    0     0 Z     0.0  0.0   0:00 netstat <defunct>
20908 kitty      6   0 19284  18M  8920 S     0.0  3.7   0:06 netscape-commun
20946 kitty      6   0  1080 1080   988 S     0.0  0.2   0:00 mozilla
20996 kitty     12   0  1088 1088   996 S     0.0  0.2   0:00 mozilla
20997 kitty      6   0  1544 1544  1324 S     0.0  0.2   0:00 mozilla-xremote
20879 kitty      6   0 44108  43M 15352 S     0.0  8.5   0:00 mozilla-bin
20825 kitty      6   0 44108  43M 15352 S     0.0  8.5   0:01 mozilla-bin
20824 kitty      6   0 44108  43M 15352 S     0.0  8.5   0:00 mozilla-bin
20823 kitty      6   0 44108  43M 15352 S     0.0  8.5   0:06 mozilla-bin
20822 kitty      6   0 44108  43M 15352 S     0.0  8.5   0:00 mozilla-bin


I don't know if this is fixed in a recent build. I have seen this behaviour for
a long time and hence I thought getting a recent build would not make much
difference. However I can try to get a newer build. As I have noted in the
reproducability category, I am not always able to get this but this happens
quite often than I would like to ignore. This is a kind of a show-stopper for me
as I have to use another browser for download or copy the link to get the file
by wget. Also the above method doesn't work for links which are not directly
downloadable.
I could reproduce this again. This time with Mozilla Build ID 2002012308
installed (only Navigator no other components) from
mozilla-i686-pc-linux-gnu-sea.tar.gz. Again I am attaching the trace with
attaching gdb to the hung process. I guess my compiling with non-standard
options (optimizations) and old builds can be eliminated. FWIW, I have set the
option to close the download window after the download completes. 

BTW, this time I was downloading the XFree86 4.2 source rpm. All my downloads
are to a local disk and not to some mounted NFS filesystem.

GDB Trace:

Loaded symbols for /usr/local/mozilla/components/libfileview.so
0x401d7a45 in PR_EnterMonitor () from ./libnspr4.so
kitty> bt
#0  0x401d7a45 in PR_EnterMonitor () from ./libnspr4.so
#1  0x4014bd81 in nsPipe::nsPipeInputStream::ReadSegments () from ./libxpcom.so
#2  0x4014c1a3 in nsPipe::nsPipeInputStream::Read () from ./libxpcom.so
#3  0x4064b730 in NSGetModule () from
/usr/local/mozilla/components/libembedcomponents.so
#4  0x41ba0e0e in NSGetModule () from /usr/local/mozilla/components/libnecko2.so
#5  0x41ba18e3 in NSGetModule () from /usr/local/mozilla/components/libnecko2.so
#6  0x40815a5a in NSGetModule () from /usr/local/mozilla/components/libnecko.so
#7  0x408090e4 in NSGetModule () from /usr/local/mozilla/components/libnecko.so
#8  0x401613c7 in PL_HandleEvent () from ./libxpcom.so
#9  0x401612e3 in PL_ProcessPendingEvents () from ./libxpcom.so
#10 0x40162218 in nsEventQueueImpl::ProcessPendingEvents () from ./libxpcom.so
#11 0x406f1243 in NSGetModule () from
/usr/local/mozilla/components/libwidget_gtk.so
#12 0x406f0fbd in NSGetModule () from
/usr/local/mozilla/components/libwidget_gtk.so
#13 0x4038ef9e in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0
#14 0x40390773 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#15 0x40390d39 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#16 0x40390eec in g_main_run () from /usr/lib/libglib-1.2.so.0
#17 0x402ab333 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#18 0x406f16d4 in NSGetModule () from
/usr/local/mozilla/components/libwidget_gtk.so
#19 0x406d132e in NSGetModule () from
/usr/local/mozilla/components/libnsappshell.so
#20 0x0804fdd9 in main1 ()
#21 0x08050627 in main ()
#22 0x404d7627 in __libc_start_main (main=0x80504f8 <main>, argc=1,
ubp_av=0xbffff4c4, init=0x804bf50 <_init>, fini=0x8051a80 <_fini>,
rtld_fini=0x4000dcc4 <_dl_fini>, stack_end=0xbffff4bc) at
../sysdeps/generic/libc-start.c:129

kitty> info threads
  6 Thread 28677 (LWP 25613)  0x404e9b85 in __sigsuspend (set=0x42391954) at
../sysdeps/unix/sysv/linux/sigsuspend.c:45
  5 Thread 3076 (LWP 25581)  0x404e9b85 in __sigsuspend (set=0x412b698c) at
../sysdeps/unix/sysv/linux/sigsuspend.c:45
  4 Thread 2051 (LWP 25580)  0x404e9b85 in __sigsuspend (set=0x40d2c97c) at
../sysdeps/unix/sysv/linux/sigsuspend.c:45
  3 Thread 1026 (LWP 25579)  0x405a0e17 in __poll (fds=0x40b2c864, nfds=2,
timeout=35000) at ../sysdeps/unix/sysv/linux/poll.c:63
  2 Thread 2049 (LWP 25578)  0x405a0e17 in __poll (fds=0x80eca44, nfds=1,
timeout=2000) at ../sysdeps/unix/sysv/linux/poll.c:63
  1 Thread 1024 (LWP 25576)  0x401d7a45 in PR_EnterMonitor () from ./libnspr4.so

kitty> thread 1
[Switching to thread 1 (Thread 1024 (LWP 25576))]#0  0x401d7a45 in
PR_EnterMonitor () from ./libnspr4.so
kitty> bt
#0  0x401d7a45 in PR_EnterMonitor () from ./libnspr4.so
#1  0x4014bd81 in nsPipe::nsPipeInputStream::ReadSegments () from ./libxpcom.so
#2  0x4014c1a3 in nsPipe::nsPipeInputStream::Read () from ./libxpcom.so
#3  0x4064b730 in NSGetModule () from
/usr/local/mozilla/components/libembedcomponents.so
#4  0x41ba0e0e in NSGetModule () from /usr/local/mozilla/components/libnecko2.so
#5  0x41ba18e3 in NSGetModule () from /usr/local/mozilla/components/libnecko2.so
#6  0x40815a5a in NSGetModule () from /usr/local/mozilla/components/libnecko.so
#7  0x408090e4 in NSGetModule () from /usr/local/mozilla/components/libnecko.so
#8  0x401613c7 in PL_HandleEvent () from ./libxpcom.so
#9  0x401612e3 in PL_ProcessPendingEvents () from ./libxpcom.so
#10 0x40162218 in nsEventQueueImpl::ProcessPendingEvents () from ./libxpcom.so
#11 0x406f1243 in NSGetModule () from
/usr/local/mozilla/components/libwidget_gtk.so
#12 0x406f0fbd in NSGetModule () from
/usr/local/mozilla/components/libwidget_gtk.so
#13 0x4038ef9e in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0
#14 0x40390773 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#15 0x40390d39 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#16 0x40390eec in g_main_run () from /usr/lib/libglib-1.2.so.0
#17 0x402ab333 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#18 0x406f16d4 in NSGetModule () from
/usr/local/mozilla/components/libwidget_gtk.so
#19 0x406d132e in NSGetModule () from
/usr/local/mozilla/components/libnsappshell.so
#20 0x0804fdd9 in main1 ()
#21 0x08050627 in main ()
#22 0x404d7627 in __libc_start_main (main=0x80504f8 <main>, argc=1,
ubp_av=0xbffff4c4, init=0x804bf50 <_init>, fini=0x8051a80 <_fini>,
rtld_fini=0x4000dcc4 <_dl_fini>, stack_end=0xbffff4bc) at
../sysdeps/generic/libc-start.c:129

kitty> thread 2
[Switching to thread 2 (Thread 2049 (LWP 25578))]#0  0x405a0e17 in __poll
(fds=0x80eca44, nfds=1, timeout=2000) at ../sysdeps/unix/sysv/linux/poll.c:63
63      ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
        in ../sysdeps/unix/sysv/linux/poll.c
kitty> bt
#0  0x405a0e17 in __poll (fds=0x80eca44, nfds=1, timeout=2000) at
../sysdeps/unix/sysv/linux/poll.c:63
#1  0x40204920 in __pthread_manager (arg=0x9) at manager.c:140
kitty> 

kitty> thread 3
[Switching to thread 3 (Thread 1026 (LWP 25579))]#0  0x405a0e17 in __poll
(fds=0x40b2c864, nfds=2, timeout=35000) at ../sysdeps/unix/sysv/linux/poll.c:63
63      in ../sysdeps/unix/sysv/linux/poll.c
kitty> bt
#0  0x405a0e17 in __poll (fds=0x40b2c864, nfds=2, timeout=35000) at
../sysdeps/unix/sysv/linux/poll.c:63
#1  0x401dabea in PR_OpenDir () from ./libnspr4.so
#2  0x401dadae in PR_Poll () from ./libnspr4.so
#3  0x40813842 in NSGetModule () from /usr/local/mozilla/components/libnecko.so
#4  0x4016378a in nsThread::Main () from ./libxpcom.so
#5  0x401dbd6e in PR_Select () from ./libnspr4.so
#6  0x40204c6f in pthread_start_thread (arg=0x40b2cbe0) at manager.c:284
kitty> 

kitty> thread 4
[Switching to thread 4 (Thread 2051 (LWP 25580))]#0  0x404e9b85 in __sigsuspend
(set=0x40d2c97c) at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
45      ../sysdeps/unix/sysv/linux/sigsuspend.c: No such file or directory.
        in ../sysdeps/unix/sysv/linux/sigsuspend.c
kitty> bt
#0  0x404e9b85 in __sigsuspend (set=0x40d2c97c) at
../sysdeps/unix/sysv/linux/sigsuspend.c:45
#1  0x402071c9 in __pthread_wait_for_restart_signal (self=0x40d2cbe0) at
pthread.c:969
#2  0x40203bdc in pthread_cond_wait (cond=0x80f8fdc, mutex=0x8116418) at
restart.h:34
#3  0x401d7809 in PR_WaitCondVar () from ./libnspr4.so
#4  0x4081b733 in NSGetModule () from /usr/local/mozilla/components/libnecko.so
#5  0x4081b286 in NSGetModule () from /usr/local/mozilla/components/libnecko.so
#6  0x4016378a in nsThread::Main () from ./libxpcom.so
#7  0x401dbd6e in PR_Select () from ./libnspr4.so
#8  0x40204c6f in pthread_start_thread (arg=0x40d2cbe0) at manager.c:284
kitty> 

kitty> thread 5
[Switching to thread 5 (Thread 3076 (LWP 25581))]#0  0x404e9b85 in __sigsuspend
(set=0x412b698c) at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
45      in ../sysdeps/unix/sysv/linux/sigsuspend.c
kitty> bt
#0  0x404e9b85 in __sigsuspend (set=0x412b698c) at
../sysdeps/unix/sysv/linux/sigsuspend.c:45
#1  0x402071c9 in __pthread_wait_for_restart_signal (self=0x412b6be0) at
pthread.c:969
#2  0x40203bdc in pthread_cond_wait (cond=0x810f164, mutex=0x8111b20) at
restart.h:34
#3  0x401d7809 in PR_WaitCondVar () from ./libnspr4.so
#4  0x40165a44 in TimerThread::Run () from ./libxpcom.so
#5  0x4016378a in nsThread::Main () from ./libxpcom.so
#6  0x401dbd6e in PR_Select () from ./libnspr4.so
#7  0x40204c6f in pthread_start_thread (arg=0x412b6be0) at manager.c:284
kitty> 

kitty> thread 6
[Switching to thread 6 (Thread 28677 (LWP 25613))]#0  0x404e9b85 in __sigsuspend
(set=0x42391954) at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
45      in ../sysdeps/unix/sysv/linux/sigsuspend.c
kitty> bt
#0  0x404e9b85 in __sigsuspend (set=0x42391954) at
../sysdeps/unix/sysv/linux/sigsuspend.c:45
#1  0x402071c9 in __pthread_wait_for_restart_signal (self=0x42391be0) at
pthread.c:969
#2  0x40203bdc in pthread_cond_wait (cond=0x80f1fd4, mutex=0x80f1f70) at
restart.h:34
#3  0x401d7809 in PR_WaitCondVar () from ./libnspr4.so
#4  0x40164385 in nsThreadPool::GetRequest () from ./libxpcom.so
#5  0x401649fe in nsThreadPoolRunnable::Run () from ./libxpcom.so
#6  0x4016378a in nsThread::Main () from ./libxpcom.so
#7  0x401dbd6e in PR_Select () from ./libnspr4.so
#8  0x40204c6f in pthread_start_thread (arg=0x42391be0) at manager.c:284
kitty> 


You might try doing a tcpdump while it's doing this... it would help to spy on
what Mozilla is doing.

Also, try enabling FTP debugging.  Before running Mozilla, set the environment
variables:

NSPR_LOG_MODULES=nsFTPProtocol:5
NSPR_LOG_FILE=ftp.121532.log

and then attach ftp.121532.log.
Any chance you are sitting behind a Cisco Pix firewall? They often mangle ftp
connections very badly and caused my Mozilla to crash in some ftp downloads.
mozilla 2002020409, win xp

i had no problems downloading the given url, which is a http url for me, not ftp.

but looking on http://www.openbsd.org/ftp.html for a OpenBSD mirror, i met some
links which really hang mozilla (memory usage does not increase, 99% processor
time):
ftp://ftp.de.openbsd.org/unix/OpenBSD
ftp://ftp.leo.org/pub/OpenBSD
ftp://ftp.fh-wolfenbuettel.de/pub/os/openbsd

btw, is there a way to break into a running win32 build of mozilla and tell
where it hangs, just like on unix/linux?
Victor:  you might be experiencing the ill effects of the fix for bug #110241. 
You might try a build before 2-1-02.

I had not noticed that the original URL here was http...  the NSPR_LOG_MODULES
thing needs to be different for http, but I don't remember what it is.
Sorry for the unnecessary attachments, I forgot to refresh the browser window.

Mozilla build 2002020603 (? it's from "2002-02-06-10-trunk" ?), winxp: all ftp
downloads work.

Thanks.
Another hang this is from static build dated 14th Feb. I am attaching the gdb
traces from attaching to the hung process. The previous hang was when running
RedHat 7.2. This is when running on Debian sid. 

I am not aware of any cisco firewall issues. I am connected directly to the
net.
Even if that is so, then how can one explain the fact that as soon as Mozilla
hangs, if I try to get the same file through wget it works and completes. So I
think that this is an issue with the browser and not with my networking setup.
tcpdump log?

no network should make a well-designed application hang or crash, but Mozilla
could easily be reacting badly to some network abnormality.

one thing I'm noticing from your build flags is the -O3.  I think most people
build with -O2 (the default is just -O, which is 1).  I have seen various bugs
concerning -O3 level optimization.  It's a bit of a long-shot, but you might try
rebuilding (netwerk at least) with -O2 and see if the bad behavior goes away.
Actually only the first build (the one with which I posted this bug report) was
compiled by me. All the other reports are with Mozilla builds that I downloaded
from ftp.mozilla.org. I will make sure that I will include the BuildId
prominently next time. In fact most of the hangs that I have reported here are
while I am downloading the latest nightly build :-(

One problem with tcpdump logs is that I am not able to reproduce this 100%. So
far when I try running with tcpdump, the downloads have succeeded. Any solutions
to getting around this other than having to run tcpdump all the time is welcome.
Maybe I should try turning on the FTP logging commands that someone suggested
earlier. 

This bug is still unconfirmed. I guess it means that only I am seeing the
problem. FWIW, Netscape 4.x and Konqueror don't seem to exhibit this problem on
the same machine.
you could start doing tcpdump while the problem is occuring.  the log for whole
connection would be HUGE.  ideally, you would use your psychic powers and start
capturing right before it started happening, but starting the log after it
started would be quite helpful.
with a hang, transferring data is not incredibly likely, so in that case it
would just confirm what one would assume anyway.  if it was managing to
send/receive during the hang, that would probably be more helpful.
Is this still reproducible in a recent nightly ( or 0.9.9 or 1.0rc1 )?
Yes. It still hangs from time to time. One more problem though I am sure that it
is related is that very often downloads complete but the file is not complete.
It is truncated and gunzip reports checksum errors. Any file downloading from
ftp sites can at best be described as unstable under Mozilla. From the same
machine, downloading via Konqueror, Netscape 4.7, wget, links, lynx etc work
flawlessly.  
Perhaps the following observation from the server point-of-view will help 
resolve this problem.

We have had feedback from a couple of Mozilla users that have had similar 
problems trying to download files from a download site of ours that runs NcFTPd. 
 The most recent report (yesterday) was from someone using a browser with this 
User Agent:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204

The symptoms were - 120 MB file downloaded just fine until the very end, where 
there was a long pause before it finally 'completed'.  The file was the correct 
size but was found to be corrupted at the very end during installation.

The NcFTPd log entries for two attempts both showed the correct, complete number 
of bytes transferred, but a status of "INCOMPLETE", which means both the data 
connection and the control connection were both closed by the client (or timed 
out) before the transfer was completed.  So, under some conditions (??), there 
appears to be a problem with Mozilla's handling of the very last block of data 
that causes it to be corrupted and the final communication with the server to be 
omitted.

> The NcFTPd log entries for two attempts both showed the correct, complete
> number of bytes transferred, but a status of "INCOMPLETE", which means
> both the data connection and the control connection were both closed by
> the client (or timed out) before the transfer was completed. So, under
> some conditions (??), there appears to be a problem with Mozilla's
> handling of the very last block of data that causes it to be corrupted
> and the final communication with the server to be omitted.

Very true. Almost all of my hangs happens towards the very end. Also the
progress  indicator seems to move smoothly but towards the end suddenly surges
and disappears in a flash before moving to 100%. In such cases, I am almost sure
that the download is not proper. So I just cut paste the URL to get it via 
wget :-( 
This maybe a problem with mozilla moving the file from the temp directory to its
real location. It might temporarily freeze if the temp directory and destination
directory are on different partitions and of sufficient size ...
Got the exact stack trace again when downloading kernel 2.5.10 from
www.kernel.org via http and not with ftp. So I guess this is genreric problem
with some timers/event handling. This is with Build Id 2002042610 on Linux.
WFM with trunk 2002073022, linux. reporter (Krishnakumar B): can you reproduce
this bug with a recent build of mozilla (for example, 1.1beta)? if so, please
comment again with details. if not, please resolve this bug as WORKSFORME. thanks.
This bug is still there. I have posted enough information already. It's the same
trace all over again. It doesn't happen always. But I do get it for large
downloads. I guess it has something to do with storing the file in the cache
directory and moving it back. My cache directory is /tmp/Cache and the most of
my downloads go to a local directory on a different disk. Note in the previous
messages that it happens only towards the end after 90% of the download is done.

If you feel it is a works for everybody, feel free to close it. I have given up
on downloading using Mozilla. I use it only as a browser.
this doesn't help us very must to get rid of this bug but ok, this will stay
open for the next time...
Some FTP problems have been solved recently. Is this still a problem with recent
nightlies.

pi
No response -> WFM

pi
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
I'll check this out and verify.
Whiteboard: checklinux
VERIFIED: Mozilla 1.4b/linux
this has worked for some time.
Status: RESOLVED → VERIFIED
Component: Networking → Networking: FTP
Summary: Mozilla hangs during ftp download → hangs during ftp download
Whiteboard: checklinux
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: