Bug 186801 - djvu images abort firefox on x86_64 FC5 system
Summary: djvu images abort firefox on x86_64 FC5 system
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: djvulibre
Version: 5
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Matthias Saou
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-03-26 16:44 UTC by Graham Campbell
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-08-19 15:18:47 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Log for a complete build of djvulibre-3.5.18 on Dell D820 (230.90 KB, text/plain)
2007-02-13 12:41 UTC, Emmanuel Kowalski
no flags Details
Output of rpm -q --requires djvulibre (766 bytes, text/plain)
2007-02-13 12:42 UTC, Emmanuel Kowalski
no flags Details

Description Graham Campbell 2006-03-26 16:44:54 UTC
Description of problem:
Plugin aborts firefox on x86_64

Version-Release number of selected component (if applicable):
djvulibre-3.5.16-3.fc5
firefox-1.5.0.1-9
#uname -r
2.6.16-1.2064_FC5

How reproducible:
Display a Web page with embedded djvu images

Steps to Reproduce:
0. Run FC5 on an x86_64 system
1.go to http://www.teletrade.com/coins/
2.select any of the lots under Thumbnail Images
3.Watch firefox disappear without any messages
  
Actual results:
Aborted firefox

Expected results:
Web page displayed with djvu images

Additional info:

Comment 1 Graham Campbell 2006-03-26 17:09:53 UTC
Just found out that firefox aborts with status code 139

Comment 2 Matthias Saou 2006-07-03 08:26:14 UTC
Sorry for the huge delay in responding, but could you please try the 3.5.17
packages that should appear real shortly and confirm if the problem still happens?

Comment 3 Graham Campbell 2006-07-04 14:13:07 UTC
I uninstalled and reinstalled the djvulibre package. I get different results
from mozilla and firefox.
Configuration:
[gc@orion ~]$ uname 
Linux orion 2.6.17-1.2139_FC5 #1 SMP Fri Jun 23 12:40:11 EDT 2006 x86_64 x86_64
x86_64 GNU/Linux
[gc@orion ~]$ rpm -q djvulibre mozilla firefox
djvulibre-3.5.17-1.fc5
mozilla-1.7.13-1.1.fc5
firefox-1.5.0.4-1.2.fc5
Results:
Mozilla - Plugin shown in "about:plugins". Aborts with segfault when I display a
page with embedded image (e.g. from teletrade.com/coins)
Firefox - No plugin shown, brings up an external viewer (djview) when a page is
shown.


Comment 4 Matthias Saou 2007-02-05 12:54:10 UTC
I've just pushed a new build of 3.5.18 for Fedora development (to be 7). Can you
easily test that? Do you want me to put some testing packages for FC6 x86_64
somewhere?

I've quickly tested 3.5.18 on an x86_64 FC6 machine, but unfortunately I'm
running an i386 firefox. I installed seamonkey, but the plugin doesn't show
up... weird, as /usr/lib64/mozilla/plugins is provided, and even a symlink in
/usr/lib64/seamonkey-1.0.7/plugins doesn't make it appear.

Comment 5 Graham Campbell 2007-02-08 14:14:47 UTC
Please put the FC6 packages somewhere, I will test. I am trying to learn enough
about xen to be able to run development systems, but it is slow going.

Comment 6 Matthias Saou 2007-02-12 19:31:19 UTC
djvulibre 3.5.18 has now been pushed to FC-5 and FC-6, so you can simply update
your system and let me know if the update fixes this issue.

Comment 7 Emmanuel Kowalski 2007-02-13 09:43:10 UTC
I have now a similar (same?) problem with djvulibre-3.5.18; this solved
Bug 228193 for me, but now the plugin aborts immediately when viewing a
web page.

On the other hand, compiling the original src.rpm file from djvulibre.org gives 
a viewer which works both in standalone and browsing mode.  So the problem
has to do with the build process.


Comment 8 Matthias Saou 2007-02-13 10:11:11 UTC
What about compiling the Fedora .src.rpm on the same system? Does that still
give you the problem?
- If yes, then it's something in the Fedora spec file, possibly the optflags
- If not, then it's something in the Fedora build system and/or build requirements

Can you test this? It will definitely help track down the problem.

Comment 9 Emmanuel Kowalski 2007-02-13 11:08:07 UTC
I just checked, and after building the src.rpm from Fedora, it works fine both
in standalone and browsing mode.


Comment 10 Matthias Saou 2007-02-13 11:42:30 UTC
Thanks a lot. Then to continue digging, I'd appreciate if you could :
- Attach the complete build output of a locally rebuilt Fedora package :
  rpmbuild ...blablabla... 2>&1 >/tmp/djvulibre.log
- Post the output of "rpm -q --requires djvulibre" for the working package.

Comment 11 Emmanuel Kowalski 2007-02-13 12:41:39 UTC
Created attachment 147982 [details]
Log for a complete build of djvulibre-3.5.18 on Dell D820

Comment 12 Emmanuel Kowalski 2007-02-13 12:42:10 UTC
Created attachment 147983 [details]
Output of rpm -q --requires djvulibre

Comment 13 Matthias Saou 2007-02-13 13:02:20 UTC
So... no differences in the requirements. So far, so good.

But the build logs shows a few differences :
- Fortran is found in your build environment (I doubt it makes any difference)
- libtool is found in your build environment (this might cause some difference)
- Lots of warnings are present during my build, but not during yours (!?)

The warnings differences are strange, since both builds are using the exact same
CFLAGS. I'll continue looking...

Comment 14 Matthias Saou 2007-02-13 13:36:11 UTC
I've been able to reproduce the problem and after some testing, here is my
conclusion : Djvulibre isn't multilib capable...
- When I install both x86_64 and i386 packages, the plugin doesn't work
- When I install _only_ the i386 package, the plugin works

Note that I have an i386 firefox installed, although my system is x86_64, in
order to get flash working. From the requirements of your rebuilt package, I
assume you do too.

I don't see any simple solution here, apart from renaming all the binaries from
one of the archs, so that no 32bit binaries get overwritten when both archs are
installed, then modifying the plugin to call the right programs... any better ideas?

For now, the workaround would be to install _only_ the package from the arch you
require, and not _both_. Can you let me know if it works for you?

Comment 15 Emmanuel Kowalski 2007-02-13 14:09:39 UTC
Actually my laptop is not x86_64 (Core Duo, not Core 2 Duo).

Curiously, I've just tried again the updated rpm (downloaded from the extras web
site, and also re-installed via yum), and this time everything worked fine.
So in my case there is no problem left, just a strange situation.

Maybe the overall yum update this morning picked the wrong package the first
time?


Comment 16 Matthias Saou 2007-06-19 15:43:27 UTC
Can you give the latest 3.5.19-2.fc8 package a try?
http://koji.fedoraproject.org/koji/buildinfo?buildID=8589
Don't mind the fc8 tag, it should install and run fine on Fedora 7. If it works
now, I think I won't go looking any further and close this bug... it's confused
me more than enough already ;-)

Comment 17 Matthias Saou 2007-08-19 15:18:47 UTC
I still haven't been able to reproduce the problem with the latest package, so
I'll close as WORKSFORME. Please reopen the bug if you manage to still see it.


Note You need to log in before you can comment on or make changes to this bug.