161511 - freezes after saving a file

Status: RESOLVED WORKSFORME

(Core :: Networking, defect)

Description

[Ramón García]

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.

Comment 1

[alge]

could you please try with a recent nightly? 1.0 is rather .. old ..

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 3

[Doug Turner (:dougt)]

dbaron, what are you using?

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 5

[Darin Fisher]

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?

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 7

[Darin Fisher]

right, i've noticed the same thing since upgrading to redhat 8.

Comment 8

[Doug Turner (:dougt)]

darin, dbaron, do either of you want to investigate this?  

Comment 9

[Darin Fisher]

dbaron: if you can get stacktraces for the other threads... it should be
possible to figure out the problem.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 11

[Darin Fisher]

dbaron: ok, thanks.  dougt: feel free to reassign this one to me.

Comment 12

[Rembert Oldenboom]

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?

Comment 13

[Darin Fisher]

rembert: does it always happen on the same pages?  can you tell us some URLs
where you've observed the problem?  thx!

Comment 14

[Doug Turner (:dougt)]

-> darin

Comment 15

[Darin Fisher]

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.

Comment 16

[Rembert Oldenboom]

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.

Comment 17

[Darin Fisher]

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!

Comment 18

[dennis bloodnok]

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.

Comment 19

[Darin Fisher]

dennis: thanks for the info.  a pstack trace would be very helpful indeed.  thx!

Comment 20

[dennis bloodnok]

Attachment: pstack from 6am, 24jan2003

Comment 21

[dennis bloodnok]

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

Comment 22

[benc]

is this still happening to anyone post 1.4RC2?

Comment 23

[Paul Bade]

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
[e-mail]

Comment 24

[OstGote!]

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.

Comment 25

[OstGote!]

Feel free to reopen if someone can reproduce this with a current build.