11018 - failure to load resource:, file:, ftp: URLs as a non-root user

Status: VERIFIED WORKSFORME

(Core :: Networking, defect, P3)

Description

[Greg Roelofs]

CVS -A pull from about 19990730 21:30:  the page above is the only one that will
even render so far, and only in viewer (apprunner pops up a gray window with no
buttons or menus and does nothing at all).  Only one font face and size (normal
Roman) renders on the entire page; links are not colored or underlined;
paragraphs are ignored; UL lists are ignored; horizontal rules are ignored;
image-loading is extremely slow; header text is duplicated.  Also, the following
error is printed on the command line:

CSSLoaderImpl::LoadAgentSheet: Load of URL 'resource:/res/ua.css' failed.  Error
code: 65535
open of resource:/res/ua.css failed: error=ffffffff
Note: frameverifytree is disabled
Assertion: "unexpected child list name" (!aListName) at file nsHTMLFrame.cpp,
line 158
Note: verifyreflow is disabled

Local web pages fail to load altogether (infinite "Connecting to
file:///foo.html").

Greg Roelofs

Comment 1

[troy]

Something's wrong with your build. If ua.css doesn't load (or isn't found) then
things won't work very well

Comment 2

[Greg Roelofs]

Okaaaaay...so it ua.css loads OK on your Linux systems?

Here are my relevant messages:

Using '/util/www/mozilla/dist/bin' as the resource: base
CSSLoaderImpl::LoadAgentSheet: Load of URL 'resource:/res/ua.css' failed.  Error
code: 65535
open of resource:/res/ua.css failed: error=ffffffff

...and here's the file:

> ls -lL /util/www/mozilla/dist/bin/res/ua.css
-rw-r--r--   1 roelofs  users       17867 Jul 30 21:24
/util/www/mozilla/dist/bin/res/ua.css

It appears to be healthy (no obvious truncation or garbling), and a fresh CVS
pull last night at 23:30 when the tree was as green as it ever gets (modulo
random orangeness in Linuxland) neither updated the file nor fixed the loading
problem. I guess I'll try a new clobber build and see if that helps, but I'm not
very hopeful.

Since the code in LoadAgentSheet strongly suggests it's a Necko bug, I'll change
the component over to that.  Failure to load file: and ftp: URLs is presumably
more of the same thing.

System:  Linux 2.0.36, libc5, gcc 2.7.2.3, P100, clobber_all build as of two
days ago (only one semi-working build and one additional pull since first
post-Necko pull of 19990730 21:30), configure with no options.

Comment 3

[Greg Roelofs]

updating the summary line so it's more precise

Comment 4

[leger]

Clearing WorksForMe resolution due to reopen.

Comment 5

[Gagan]

Greg:
we have been building and using/running the Linux builds successfully. Though I
am not sure of your specific combination of the compiler and os versions, I am
convinced that we are not having this problem here. If you could try pulling
fresh and doing a clobber (make sure you remove mozilla/netwerk/dist) and
letting us know if your problem is still there. I am closing this again as
worksforme since it does.

Comment 6

[Greg Roelofs]

OK, I did a fresh pull this morning, configured with optimization on, did a
clobber_all (which completed successfully), and fired up a build before I left
for work.  I'll give it another go tonight and see if it worked.

Thanks for the feedback!

Comment 7

[Greg Roelofs]

Well, a complete clobber_all rebuild and wipe of ~/.mozilla didn't help:  file,
ftp and resource URLs still don't work for me (viewer), http URLs are still
incredibly slow, and there are no error messages to indicate what's wrong
(beyond an informational message about "nsWidget::RealizeSignal(0x80fe400)").
apprunner is even worse; it throws up a blank window, prints
"nsWidget::RealizeSignal(0x8102b00)", and does nothing at all.

I guess I'll wait and see if Tenthumbs' libc5 build does anything...I don't
really have time to go digging through Necko on my own.

Comment 8

[Jip de Bugzilla]

same problem here since necko landed,
even on a glibc-2.0.7 system.
Upgraded to glibc-2.1.1 and the problem is still here.
Maybe there are some other antique libs hanging around here?

Comment 9

[Greg Roelofs]

These are the only non-Mozilla, non-GTK shared libs that ldd shows:
        libdl.so.1 => /lib/libdl.so.1 (0x404cf000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x404d2000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x404db000)
        libm.so.5 => /lib/libm.so.5 (0x40568000)
        libstdc++.so.27 => /usr/lib/libstdc++.so.27 (0x40571000)
        libc.so.5 => /lib/libc.so.5 (0x405a0000)
It doesn't seem to be a libc problem, and presumably it's not an X or math-lib
problem, so the most likely candidates would be libdl.so.1 and libstdc++.so.27.
Here are my specific versions of those:
        libstdc++.so.27 => libstdc++.so.27.2.8
        libdl.so.1 => libdl.so.1.9.5
Does that ring any bells for anyone?  I'm sticking Ramiro the Unix god on the cc
list just in case he might know...

Also, pip:  could you try http://www.cdrom.com/pub/png/pngs-img.html and see if
anything but the two GIFs and one JPEG shows up?  I suspect this might be
related (bug 11019).  Thanks.

Comment 10

[Jip de Bugzilla]

These are the only non-Mozilla, non-GTK shared libs that my ldd ./viewer shows:
  libz.so.1 => /usr/local/lib/libz.so.1 (0x4001d000)
  libplds3.so => /usr/local/nspr/lib//libplds3.so (0x4002d000)
  libplc3.so => /usr/local/nspr/lib//libplc3.so (0x40032000)
  libnspr3.so => /usr/local/nspr/lib//libnspr3.so (0x40037000)
  libpthread.so.0 => /lib/libpthread.so.0 (0x40073000)
  libdl.so.2 => /lib/libdl.so.2 (0x4024d000)
  libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40250000)
  libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4025b000)
  libnsl.so.1 => /lib/libnsl.so.1 (0x402f2000)
  libutil.so.1 => /lib/libutil.so.1 (0x40308000)
  libresolv.so.2 => /lib/libresolv.so.2 (0x4030b000)
  libm.so.6 => /lib/libm.so.6 (0x4031a000)
  libstdc++-libc6.1-1.so.2 => /usr/lib/libstdc++-libc6.1-1.so.2 (0x4033600
0)
  libc.so.6 => /lib/libc.so.6 (0x40378000)
  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Linux 2.2.6 pentium75 64MB
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

http://www.cdrom.com/pub/png/pngs-img.html shows a lot of images for me,
including all the png's i think.

...
Going to create the event queue
GFX: dpi=96 t2p=0.0666667 p2t=15 depth=16
Using '/usr/home/jip/moz/gtk/dist/bin' as the resource: base
nsWidget::RealizeSignal(0x80f34f8)
Got the event queue from the service
Calling gdk_input_add with event queue
CSSLoaderImpl::LoadAgentSheet: Load of URL 'resource:/res/ua.css' failed.  Error
code: 65535
open of resource:/res/ua.css failed: error=ffffffff
Note: frameverifytree is disabled
Assertion: "unexpected child list name" (!aListName) at file
../../../../../mozilla/layout/html/base/src/nsHTMLFrame.cpp, line 158
Note: verifyreflow is disabled
...

can't really garantee a clean build, lot's of upgraderitus (bug 8846),
and badblocks on my root partition. But i did do a few fresh checkouts
and builds since necko landed.

Comment 11

[Jip de Bugzilla]

"lot's of upgraderitus (bug 8846)", should link to bug 8849 offcourse.

Comment 12

[Chris Petersen]

With the latest Linux build, all images and text on this page are rendered correctly.

Comment 13

[Jip de Bugzilla]

I don't really know what this means:

Same problem when running viewer and apprunner normally.
cvs co at Aug 8

but when i run 'strace ./apprunner' or 'nice -n -19 ./apprunner',
i get a working apprunner (or viewer).

I noticed tentumbs had a pentium100, i have a pentium75,
maybe its a timing thingie?

Comment 14

[Greg Roelofs]

Fascinating...I too have a P100, and I verified that the problem goes away for
me, as well (at least with file: and resource: URLs) when I run viewer at a
/usr/bin/nice level of -19 (as root, of course).  However, I also found that it
*still* works if I run it as root without any change in the niceness.  Presence
or absence of ~/.mozilla doesn't seem to make any difference; root's was empty,
but when I nuked my own and reran in exactly the same way, it still didn't work.
But maybe root naturally runs at a slightly higher priority?  Shell was tcsh in
either case, using /usr/bin/nice.

I tried an strace run (as me), but it spent upward of 10 minutes just doing an
ungodly number of seeks/reads of 32-, 39- and 16-byte chunks.  Then it got
started on about a billion mmaps, all of which failed:

mmap(0, 15446016, PROT_READ|PROT_WRITE, MAP_PRIVATE, 4294967295, 0) = -1 EBADF
(Bad file number)
mmap(0, 15441920, PROT_READ|PROT_WRITE, MAP_PRIVATE, 4294967295, 0) = -1 EBADF
(Bad file number)
mmap(0, 15437824, PROT_READ|PROT_WRITE, MAP_PRIVATE, 4294967295, 0) = -1 EBADF
(Bad file number)
mmap(0, 15433728, PROT_READ|PROT_WRITE, MAP_PRIVATE, 4294967295, 0) = -1 EBADF
(Bad file number)
mmap(0, 15429632, PROT_READ|PROT_WRITE, MAP_PRIVATE, 4294967295, 0) = -1 EBADF
(Bad file number)
mmap(0, 15425536, PROT_READ|PROT_WRITE, MAP_PRIVATE, 4294967295, 0) = -1 EBADF
(Bad file number)
mmap(0, 15421440, PROT_READ|PROT_WRITE, MAP_PRIVATE, 4294967295, 0) = -1 EBADF
(Bad file number)
mmap(0, 15417344, PROT_READ|PROT_WRITE, MAP_PRIVATE, 4294967295, 0) = -1 EBADF
(Bad file number)

Those started at around 133 million and counted down through at least 6 cycles.
(I don't know what Mozilla is trying to do, but you'd think it would catch on
after a couple hundred thousand failures...)  I had to kill it after 20 minutes
without any window, but I'll try to leave it running tonight when I go to bed
and see if it ever does anything.

Btw, gdb makes no difference:  as me, I get only black spinning numbers and no
output (file: URL); as root, I get the blue throbber and everything (except
PNGs) works.  That suggests that it might not be a timing issue after all--or at
least not the usual kind.

Comment 15

[Jip de Bugzilla]

Changed summary.
m9 binary release and cvs builds still only works as root for me.

Comment 16

[Jip de Bugzilla]

Wowzers, somewhere between 0:00 Friday 12 sep, and late saturday??????
13 sep, something made my viewer and apprunner work again with
a normal user account.?????? Thanks who or whatever.

Comment 17

[leger]

Bulk move of all Necko (to be deleted component) bugs to new Networking

component.