Closed Bug 6323 Opened 25 years ago Closed 25 years ago

PNGs and JPEGs aren't displayed on FreeBSD

Categories

(Core :: Graphics: ImageLib, defect, P3)

Product:
Core
Component:
Graphics: ImageLib
Platform:
x86
FreeBSD
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: lennox, Assigned: toshok)

References

Details

(Whiteboard: HELP WANTED)

Attachments

(1 file)

Patch to make gFactory declarations static
1.12 KB, patch
Details | Diff | Splinter Review 
With a current apprunner build on FreeBSD, JPEG and PNG images aren't displayed
-- or, rather, they seem to be displayed as one-pixel dots.  I don't know if
this is the old shared library problem again (libnspng.so needing to pull in
libpng.so.2) or something else.  I *do* have both libpng.so and libjpeg.so
installed in my system, and configure is using them.

I'm testing this by going to the "JPEG images" and "PNG images" tests in the
Debug menu.
Status: NEW → ASSIGNED
Target Milestone: M7
Yep. it sounds like the lib problem again.
If you see gif's, the decoder component load is working.

Sometimes this happens if you have files left over from
previous builds. Local clobbers won't fix it. Try a top level
make with realclean.
Take a look at bug#5842.
I did a clobber_all (the same as realclean, I believe), and rebuilt with a fresh
tree from this morning.  The problem's still there.

Yes, GIFs are working fine.
Another observation -- running ktrace on the binary shows that
/usr/local/lib/libpng.so.2 *is* getting loaded, right after libnspng is -- or at
least it's getting an open(), read(), and mmap(), which is all the ktrace will
tell me.  So I guess the problem must be more complicated than I thought?
Target Milestone: M7 → M9
Don't worry about the milestone change. This is still on my radar.
-pn
*** Bug 7831 has been marked as a duplicate of this bug. ***
bu 8415 depends on this. addin myself to cc
Blocks: 8415
telnet://shiver is running FreeBSD 2.2.7-STABLE
If you guys need an account on a FreeBSD-3.2 box to work on, mail me.
I don't know how much resources you need -- I don't own a supercomputer :)
adding green@unixhelp.org who reported bug 7831 (a duplicate of this)
and toshok, who says he was recently able to display png with his "freebsd
3.2-RELEASE" build. Could the rest of you freebsd people rebuild and verify
you still have the problem? Also report your os version and whether you have
libpng and libjpg installed. If so, which version.
And whether you are linking with moz png and jpeg libs or your
native png and jpeg libs.....
-pn
buid# 1999062312 on FreeBSD 3.1 release
I now have the path to the png image displayed instead of the one pixel dot.
Jpegs are still displayed as a one pixel dot.
I just tried the M7 release built with egcs 1.1.2 on FreeBSD 3.2-RELEASE, and
the problem's still there.  Using and linking with the system installed libpng
1.0.2 and libjpg 6b.

I'll try last night's last-known-good build next.
I'm still seeing the problem with the July 2 tree.  PNGs now display their alt
text instead of loading; JPEGs still display as a single dot.  Same specs as my
previous comment.
Would you try forcing the build to use your mozilla libraries
instead of linking in your bsd native libs? You will have to
check autoconf, but I believe the option is configure --with-png.

I have heard of several people having trouble with png and jpeg libs
on bsd...but I have also heard of people on bsd having no trouble with png
and jpeg decoders.

When the image is displayed as a one pixel image, the decoder is not linked
properly with the jpeg or png library.

-pn
I configured with "./configure --with-png=no --with-jpeg=no", which from
configure.in seems to be how you do that.  libnspng.so and libnsjpg now have the
symbols in them, but the problem is still there, same as it was.
Maybe someone should enquire on a FreeBSD list.  I'm sure someone there will be
interested in getting Mozilla to work on their OS.
Whiteboard: HELP WANTED
Adding HELP WANTED notice.
Mozilla should work with either the jpg and png libraries that come with the
mozilla tree or with standard native libpng and libjpg that come with the
system. Pam needs someone to build on BSD both with the mozilla libraries
and with the native libraries. She suspects a problem with the build system.
Perhaps configure is mis-detecting the presence of native libraries and links
with the wrong thing.
the problem is with the build system because if my memory is correct before
imglib landed we used to have jpegs.

pete
Did some testing on some donated time on a bsd machine.
Unfortunately, the theories with an easy fix don't appear to
be the problem. Even if autoconf is set up to only use the
mozilla jpeg and png libs (--without-png --without-jpeg ) the
symptoms remain the same.

Here is what you can tell from the symptoms:
Instead of image, you see a single dot:  the decoder wrapper is loaded, but
   something is wrong with the linkage to the format decoder. Perhaps the
   decoder lib is _bad_ for some reason, or the wrong decoder wrapper has
   been loaded.

Instead of image, you see the text filename of the image: This is an error
   condition. The image file was not found, the decoder component was not
   found. This used to be a broken image icon but a  decision was made
   to have the alt text or filename display instead. (not my decision, send
   differing opinions to the layout folks.).
Target Milestone: M9 → M10
OK, gang.
We need a bsd wiz to track this down.
I can't get gdb to run viewer. And if I can't
use the debugger on viewer (or apprunner), I'm
sunk.

I created a build where I forced the jpeg component to link
with the mozilla jpeg lib. I don't completely believe that autoconf is
doing the right thing with the "--without-jpeg" switches.
When I link and run viewer, I see the image file name displayed
indicating an error that I could pinpoint, if the debugger would run.
None of the other unixes seem to be having this problem.

Any volunteers?
If this is a build problem, the problem is more than likely occurring in the
compiler flags or link flags used for FreeBSD. As Pam stated, none of the other
unices seem to have this problem and those flags are usually the biggest
difference between platforms.  I checked configure and the behavior of
--without-jpeg seems to be correct.  When --with-jpeg=no or --without-jpeg is
used, SYSTEM_JPEG is unset which also causes MOZ_NATIVE_JPEG to be unset in
config/autoconf.mk.  This causes Mozilla to use the hardcode JPEG_CFLAGS &
JPEG_LIBS set in config/autoconf.mk.  PNG uses pretty much the same method.

Everything looks fine except that JPEG_CFLAGS is set to -I$(DIST)/public/jpeg.
We switched from using the public dir a while ago but this shouldn't affect
anything as $(DIST)/include is in our default include path.

Erk, scratch that..we still have this year old problem that we are testing for
MOZPNG=95 when we should have version 1.0.2 or so in the tree.  That should only
cause a problem if the user's version of png is less than 1.0.2 but higher than
0.95 and we use features/behavior that is dependent upon 1.0.2.  In any case,
this should've been bumped long ago.  I'm bumping it now.  But according to
these reports the problem occurs regardless of which libjpeg or libpng is used.
well i gues someone fixed jpegs.
i have a fresh build and can view jpegs with viewer.
aprunner hangs upon startup so i can't validate it there.

pete
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Pete tells me he is seeing pngs and jpeg with
the most current build. (M9).

The problem was fixed by dp's COM changes.
Apparently, there was a problem with component
loading just for bsd.
I have not yet heard if chris has made changes
in autoconf to update the png version test.

-pn
[e-mailed pinged lennox@cs.columbia.edu to request confirmation that it's fully
fixed, as we don't have a FreeBSD system around.]
Status: RESOLVED → VERIFIED
[lennox@cs.columbia.edu confirms that it works for him, too. Thus, rubber-
stamping as Verified Fixed.]
pam, just a note about verify png's.

when i first try to view a png in viewer.
It does not display. I get the old address of the image.
Then viewer crashes.
when i restart and view the same png URL - i can now see it.

So there is still a lurker in there somewhere.

pete
p.s.

after the png loads i get an Assertion:

Assertion: "mForegroundCount messed up" (mForegroundCount > 0) at file
nsLoadGroup.cpp, line 459

pete
I'll have to pull this morning's tree, but I think
this was identified and fixed over the weekend.
It happens on all platforms.

-pn
Uh-oh.. I'm going to re-open this one again.

Everything seemed fine, except .jpg's aren't displayed anymore --
they are routed through the .png decoder, which (correctly) claims
that what it gets isn't a .png! Oops... .PNG seem to work nicely
though.

This happened _after_ the merge of the m9 tree into the nightly
builds. Before that merge, .JPG's displayed correctly, but .PNG's
didnt.

I've only tested this on today's source code... Correct me if this
is just an insane hallucination or a regression in today's code.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
[clearing resolution]
Has anyone else seen problems with image decoders loading
since m9? The problem described with the reopening of this
bug may be caused by not clobbering the build after updating.

Let me know if you are still seeing a problem after you have
tried rebuilding after doing a 'clobber all'.
Hellllllloooooo?
Are the components loading or not loading?
Need your input....

-pn
We were having some problems with Perl due to some changes to the rtld-elf code
on FreeBSD-4.0-CURRENT (which is our only available build platform right now)
These problems have just been fixed .. so I am building Mozilla right now to
find out the current status on the component loading.

Pascal (daeron@shadowmere.student.utwente.nl)
Theo (havoc@phoenix.student.utwente.nl)
Ok ... my most recent build shows no problems at all using PNGs and/or JPEGs on a FreeBSD-4.0-CURRENT system ...
I think we can close down the bug as fixed.

Build ID: 1999082316
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
marking fixed per daeron's comment.
Status: RESOLVED → REOPENED
Okay, I've tried this on FreeBSD-3.2 -- Friday's last-known-good tree
(09/03/1999 14:59:32 PDT), compiled with egcs 1.1.2, and I'm still having
problems, so I've reopened this bug.

Here's what I'm seeing:  I can view either PNGs *or* JPGs, but once I've viewed
one of them, it becomes impossible to view the other.  (If I view a PNG first,
JPGs show up as a single dot; if I view a JPG first, PNGs show up as their ALT
tags.)

It looks like both PNGs and JPGs are getting routed to whichever component got
loaded first.  If a PNG got loaded first, trying to view a JPG will result in
"nspng libpng error: Not a PNG file" being printed on the debug output.  libjpeg
isn't as chatty, apparently...

I configured with --without-png --without-jpg so the build wouldn't try to use
my system versions of libpng and libjpg, but would instead build its own.
Symptoms when I used the system libraries were somewhat similar, but I hadn't
completely figured out the nature of the problem yet so I can't say for sure.

Note: I only tried this on viewer, since bug 13154 prevented me from running
apprunner.

I'm using resource:/res/samples/test2.html for my sample JPEG (the dinosaur),
and http://www.cdrom.com/pub/png/ and descendant pages for sample PNGs.
The only difference I can find between the "Broken FreeBSD" and the "Working FreeBSD" builds ... are the facts that the working builds are created on my 4.0-CURRENT system using system png and jpeg libraries, instead of Mozilla's own versions. I checked again with code just updated (--clobber) and I do not have problems with either JPG or PNG images no matter in what order the images are loaded. PNG/JPEG/PNG works just fine as well as JPEG/PNG/JPEG.

I guess this is a 3.x-only bug then.
Assignee: pnunn → dp
Status: REOPENED → NEW
From lennox's comments, it sounds like the components are
loading ok, but not unloading. I'm reassigning to dp, since
he may have insight on problems related to component unloading.
-pn
Assignee: dp → toshok
Toshok can you help us with this ?
Yep, i can confirm. You can either view jpeg or png. Not both in the same
session.  This is only for viewer since freeBSD hasn't been able to run
apprunner for almost two weeks now.  Perpetual browness!

pete
Okay, a new discovery: --enable-low-fat (which strips symbols out of component
libraries) works around this problem, and a huge number of other ones, on
FreeBSD.  It causes its own problems, though, namely spewing "Ignored d_tag "
messages to stdout...I'll try to track this one down and file it as a separate
bug report.
Okay, I've got a fix for this problem -- but I don't believe it's really fixing
the root cause.

The problem is coming about because both libnspng.so and libnsjpg.so define a
global symbol "gFactory".  Because of FreeBSD's "pick the first symbol" bug
(discussed in bug 13154), we're seeing the behavior described.

The patch I've attached (to declare gFactory as static) fixes the problem in
this case, and is fine from a code-cleanliness point of view anyway, but doesn't
get at the root cause of the problem.  There's enough copy&pasted code in
Mozilla that trying to find every multiply-declared symbol and declare it static
is certainly an impossible task...
Pam can you take care of applying the patch in imglib to get freebsd working
again.
sure. no problem.
-pn
I just checked in the 2 changes but I'm not marking
this as fixed. Only you BSD folk can decide if this is
fixed or not.

Thanks, lennox!
-pn
Target Milestone: M10 → M11
m10 buyg list cleanup.-> m11
Assignee: toshok → toshok
Reassigning to toshok@hungry.com; toshok@netscape.com is no longer valid.
Target Milestone: M11 → M12
can some one on freebsd check this out?
I can confirm jpg's and png's work on a build from yesterday on viewer only.
apprunner is not working on freeBSD yet.

pete
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
sounds like we can mark this one fixed and verify on
on ./mozilla when it appears on free bsd.
I agree i believe this one is fixed.
I have been working to try to track down a new bug on FreeBSD that has to do
with unicode and CSS paths. The converter stream is busted.
I am not filing this as a bug because I know freeBSD is not being supported.

Lennox -- Is apprunner working for you??

any help would be an awsome thing!

pete
[Pinged lennox@cs.columbia.edu for his $.02.

Will rubber-stamp as Verified/FIXED by end of week if nobody is seeing this.]
Status: RESOLVED → VERIFIED
It's the end of week...do you know where your FreeBSD users who aren't seeing
PNGs and JPEGs are? ;)

But, seriously, verifying as fixed by virtue of lack of protest. If anyone is
still seeing this issue on a current build, please re-open with your comments.

Thanks!
I think you can close this one.

I would love to verify this for you but i can't.

All FreeBSD versions accept for 4.0 Current are failing to run apprunner and
viewer.
See: http://bugzilla.mozilla.org/show_bug.cgi?id=20857

pete
Depends on: 20857
depends on 20857, FreeBSD needs to startup properly.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: