All users were logged out of Bugzilla on October 13th, 2018

freezes after saving a file

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
16 years ago
14 years ago

People

(Reporter: ramon_garcia_f, Assigned: darin.moz)

Tracking

({hang})

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [need more stack traces])

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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

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

Updated

16 years ago
Keywords: hang
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

Comment 3

16 years ago
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.
(Assignee)

Comment 5

16 years ago
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.
(Assignee)

Comment 7

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

Comment 8

16 years ago
darin, dbaron, do either of you want to investigate this?  
(Assignee)

Comment 9

16 years ago
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.
(Assignee)

Comment 11

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

Comment 12

16 years ago
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?
(Assignee)

Comment 13

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

Comment 14

16 years ago
-> darin
Assignee: dougt → darin
(Assignee)

Comment 15

16 years ago
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]

Comment 16

16 years ago
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.
(Assignee)

Comment 17

16 years ago
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

16 years ago
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.
(Assignee)

Comment 19

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

Comment 20

16 years ago
Created attachment 112517 [details]
pstack from 6am, 24jan2003

Comment 21

16 years ago
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

16 years ago
is this still happening to anyone post 1.4RC2?
Summary: Mozilla freezes after saving a file. → freezes after saving a file

Comment 23

16 years ago
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
pabade@prairie.lakes.com

Comment 24

14 years ago
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

14 years ago
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.