Closed
Bug 121532
Opened 23 years ago
Closed 22 years ago
hangs during ftp download
Categories
(Core Graveyard :: Networking: FTP, defect)
Tracking
(Not tracked)
VERIFIED
WORKSFORME
People
(Reporter: kitty, Assigned: neeti)
References
()
Details
Attachments
(5 files)
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.
Reporter | ||
Comment 1•23 years ago
|
||
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>
Comment 2•23 years ago
|
||
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.
Comment 3•23 years ago
|
||
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.
Comment 4•23 years ago
|
||
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?
Comment 5•23 years ago
|
||
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.
Comment 6•23 years ago
|
||
Comment 7•23 years ago
|
||
Comment 8•23 years ago
|
||
Comment 9•23 years ago
|
||
Comment 10•23 years ago
|
||
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.
Reporter | ||
Comment 11•23 years ago
|
||
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.
Comment 12•23 years ago
|
||
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.
Reporter | ||
Comment 13•23 years ago
|
||
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.
Comment 14•23 years ago
|
||
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.
Comment 15•23 years ago
|
||
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.
Comment 16•22 years ago
|
||
Is this still reproducible in a recent nightly ( or 0.9.9 or 1.0rc1 )?
Reporter | ||
Comment 17•22 years ago
|
||
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.
Comment 18•22 years ago
|
||
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.
Reporter | ||
Comment 19•22 years ago
|
||
> 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 :-(
Comment 20•22 years ago
|
||
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 ...
Reporter | ||
Comment 21•22 years ago
|
||
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.
Comment 22•22 years ago
|
||
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.
Reporter | ||
Comment 23•22 years ago
|
||
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.
Comment 24•22 years ago
|
||
this doesn't help us very must to get rid of this bug but ok, this will stay open for the next time...
Comment 25•22 years ago
|
||
Some FTP problems have been solved recently. Is this still a problem with recent nightlies. pi
Comment 26•22 years ago
|
||
No response -> WFM pi
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Comment 28•21 years ago
|
||
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
Updated•2 months ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•