All users were logged out of Bugzilla on October 13th, 2018
Sometimes, when saving a download, Mozilla freezes completely. The problem is not reproducible. It is specially frequent when downloading a package from sourceforge, (perhaps because that downloads are programatically originated instead of being generated by the user clicking on a link). For example, go to cdex.sf.net, choose downloads. The problem does not happen always. This is Mozilla 1.0 (build by me, so build id is 0). When Mozilla freezes, one of the threads is taking 100 % CPU. If this thread is attached with GDB the following trace is found: #0 0x401dbb46 in PR_EnterMonitor () from /tmp/mozilla/libnspr4.so #1 0x401521fc in nsPipe::nsPipeInputStream::ReadSegments () from /tmp/mozilla/libxpcom.so #2 0x4015269d in nsPipe::nsPipeInputStream::Read () from /tmp/mozilla/libxpcom.so #3 0x4014f3c5 in nsInputStreamTee::Read () from /tmp/mozilla/libxpcom.so #4 0x406c0f55 in nsExternalAppHandler::OnDataAvailable () from /tmp/mozilla/components/liburiloader.so #5 0x406b7f4e in nsDocumentOpenInfo::OnDataAvailable () from /tmp/mozilla/components/liburiloader.so #6 0x4070bdaa in nsStreamListenerTee::OnDataAvailable () from /tmp/mozilla/components/libnecko.so #7 0x40744e39 in nsHttpChannel::OnDataAvailable () from /tmp/mozilla/components/libnecko.so #8 0x4070b17a in nsOnDataAvailableEvent::HandleEvent () from /tmp/mozilla/components/libnecko.so #9 0x406f6df3 in nsARequestObserverEvent::HandlePLEvent () from /tmp/mozilla/components/libnecko.so #10 0x4016bd5b in PL_HandleEvent () from /tmp/mozilla/libxpcom.so #11 0x4016bc55 in PL_ProcessPendingEvents () from /tmp/mozilla/libxpcom.so #12 0x4016ccb3 in nsEventQueueImpl::ProcessPendingEvents () from /tmp/mozilla/libxpcom.so #13 0x40816476 in event_processor_callback () Since nsPipe appeared in the trace, I am assigning to component XPCOM. From the limited analysis that I made, it seems that nsExternalAppHandler::OnDataAvailable is calling repeatedly to nsInputStreamTee::Read because this function always return 0 bytes read.
could you please try with a recent nightly? 1.0 is rather .. old ..
I just hung with the following stack on my own opt build from a few days ago, while downloading openoffice (http://www.openoffice.org/) and pressing back through the site from the download page. It was partway through the download: #0 0x40234534 in pthread_self () from /lib/i686/libpthread.so.0 #1 0x4020774f in PR_ExitMonitor () from /builds/trunk/obj/opt/dist/bin/libnspr4.so #2 0x4017319e in nsPipe::nsPipeInputStream::ReadSegments(unsigned (*)(nsIInputStream*, void*, char const*, unsigned, unsigned, unsigned*), void*, unsigned, unsigned*) () from /builds/trunk/obj/opt/dist/bin/libxpcom.so #3 0x4017357e in nsPipe::nsPipeInputStream::Read(char*, unsigned, unsigned*) () from /builds/trunk/obj/opt/dist/bin/libxpcom.so #4 0x4016f826 in nsInputStreamTee::Read(char*, unsigned, unsigned*) () from /builds/trunk/obj/opt/dist/bin/libxpcom.so #5 0x414df517 in nsExternalAppHandler::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned, unsigned) () from /builds/trunk/obj/opt/dist/bin/components/liburiloader.so #6 0x414d437d in nsDocumentOpenInfo::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned, unsigned) () from /builds/trunk/obj/opt/dist/bin/components/liburiloader.so #7 0x40901632 in nsStreamListenerTee::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned, unsigned) () from /builds/trunk/obj/opt/dist/bin/components/libnecko.so #8 0x40943ab7 in nsHttpChannel::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned, unsigned) () from /builds/trunk/obj/opt/dist/bin/components/libnecko.so #9 0x40900976 in nsOnDataAvailableEvent::HandleEvent() () from /builds/trunk/obj/opt/dist/bin/components/libnecko.so #10 0x408e9af9 in nsARequestObserverEvent::HandlePLEvent(PLEvent*) () from /builds/trunk/obj/opt/dist/bin/components/libnecko.so #11 0x4018dba7 in PL_HandleEvent () from /builds/trunk/obj/opt/dist/bin/libxpcom.so #12 0x4018dab4 in PL_ProcessPendingEvents () from /builds/trunk/obj/opt/dist/bin/libxpcom.so #13 0x4018ee7b in nsEventQueueImpl::ProcessPendingEvents() () from /builds/trunk/obj/opt/dist/bin/libxpcom.so #14 0x40d63545 in event_processor_callback(void*, int, GdkInputCondition) () from /builds/trunk/obj/opt/dist/bin/components/libwidget_gtk.so #15 0x40d6316d in our_gdk_io_invoke(_GIOChannel*, GIOCondition, void*) () from /builds/trunk/obj/opt/dist/bin/components/libwidget_gtk.so #16 0x4040a076 in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0 #17 0x4040b97e in g_main_dispatch () from /usr/lib/libglib-1.2.so.0 #18 0x4040be59 in g_main_iterate () from /usr/lib/libglib-1.2.so.0 #19 0x4040c0f4 in g_main_run () from /usr/lib/libglib-1.2.so.0 #20 0x4030a6df in gtk_main () from /usr/lib/libgtk-1.2.so.0 #21 0x40d63966 in nsAppShell::Run() () from /builds/trunk/obj/opt/dist/bin/components/libwidget_gtk.so #22 0x40d473e4 in nsAppShellService::Run() () from /builds/trunk/obj/opt/dist/bin/components/libnsappshell.so #23 0x08052981 in main1(int, char**, nsISupports*) () #24 0x080532b5 in main () #25 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
Assignee: dougt → new-network-bugs
Status: UNCONFIRMED → NEW
Component: XPCOM → Networking
Ever confirmed: true
QA Contact: scc → benc
dbaron, what are you using?
Assignee: new-network-bugs → dougt
My own optimized build (built with gcc 3.2) on Linux from a trunk tree a few days old, with all my changes in it.
dbaron: if this happens again, can you please capture stack traces of the other threads? without that it's hard to determine the cause of the deadlock. also do you have pipelining enabled?
I didn't have pipelining enabled, and ps didn't show any other threads, but maybe that's because things have changed in the new kernel -- I didn't try |inf thr| in gdb.
right, i've noticed the same thing since upgrading to redhat 8.
darin, dbaron, do either of you want to investigate this?
dbaron: if you can get stacktraces for the other threads... it should be possible to figure out the problem.
I only saw the problem once. I could try to see if I can see the problem again, but I don't know if I'll succeed.
dbaron: ok, thanks. dougt: feel free to reassign this one to me.
Similar problem. Using 1.2b Contrary to dbaron, reproducing it is easy in my situation: rightclick on image on top of this page, choose save and save it anywhere. Mozilla will freeze (and taking up to 99% of cpu resources). The file will actually be saved but Mozilla doesn't return. Same happens when saving pages. Maybe this is caused by the same problem? Or is this something else?
rembert: does it always happen on the same pages? can you tell us some URLs where you've observed the problem? thx!
Assignee: dougt → darin
these stack traces unfortunately aren't very interesting. they only suggest that someone is in a loop reading from a pipe. not clear if it is a problem w/ the pipe or w/ the nsExternalAppHandler or what. keeping untargeted until we get more info.
Whiteboard: [need more stack traces]
I tried to reproduce the problem but somehow everything is now working perfectly again. Nothing changed on the system except for the fact I've rebooted. One of the urls having this problem was this very bug page itself. Just right-click on the mozilla.org bannerlogo at the top, save it and whoppa, a freeze. Maybe a clue: when having the problem, the default save dir was set to a location where I had no write access. Browsing to another dir, saving the file worked but still that freeze. Somehow I managed to get the default dir back to my own home dir. Tried to get back to the inaccessible dir by manually tweaking browser.download.dir in prefs.js but unfortunately (?) I didn't manage to reproduce the problem. Please let me know what to do when this occurs again.
rembert: are you running linux? if so, then there is a handy utility called "pstack" (ships with redhat 8) that you can run to collect stack information from your hung process. just use "ps" to find the PID of the hung mozilla process. then run the pstack command like so: $ pstack pid run this several times to collect snapshots of the stack trace at different times. then attach the stack traces to this bug. this information might indicate the problem. thanks!
i have experienced this bug several times with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130. my box is running redhat7.3. the most recent occurance was an attempt to save a small jpeg from amazon.com. i run the browser as the stoopiduser (aka root), so write permissions aren't an issue. after killing the browser, i found a rogue process grabbing all the cpu cycles it could get its mitts on. sandbagged that and everything is indeed lovely in the garden again. next time this happens, i'll grab a pstack trace and attach it to this bug.
dennis: thanks for the info. a pstack trace would be very helpful indeed. thx!
Comment on attachment 112517 [details] pstack from 6am, 24jan2003 this showed up in the latest released build Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212
is this still happening to anyone post 1.4RC2?
Summary: Mozilla freezes after saving a file. → freezes after saving a file
Mozilla 1.2.1 on Mac OS 8.6 froze (unable to move cursor or execute keboard commands except forced restart) when I attempted to save the page http://www.mankato.msus.edu/dept/AffAct/MSU-VAC_NOT/VacHP.html#exec to an existing sub-folder of my Documents folder. The file did not appear in the folder, so my freeze occurred before the file was saved. Hardware: UMac C600, 64 MB RAM, about 30 MB free disk space. Build is Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.2.1) Gecko/20021130, default parameters. One other application was open at the time of the freeze. Paul Bade firstname.lastname@example.org
Check if your downloads.rdf file (DM history) in your profile is too large, this causes delays. Old versions (< 1.4) and over 1 year no response. I guess this bug could be resolved.
Feel free to reopen if someone can reproduce this with a current build.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.