Closed Bug 274430 Opened 20 years ago Closed 19 years ago

Dragging in "add a bookmark" -> "Name" dialog or anywhere in "bookmarks manager" causes firefox to crash.

Categories

(Firefox :: Bookmarks & History, defect)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED EXPIRED

People

(Reporter: scolloms, Assigned: vladimir+bm)

References

()

Details

(Keywords: crash)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20041212 Firefox/1.0+

I have just installed Firefox 1.0 (latest nightly build) on a redhat 9.0 box.

On dragging within bookmark dialogs as described below in "steps to reproduce"
firefox dies with the following error.

./firefox-bin: relocation error:
/usr/local/staden_linux_2003.0b1/lib/linux-binaries/libpng12.so.0: undefined
symbol: inflateInit_

firefox 0.8 and latest mozilla are both OK

seems to be a problem with my library paths?
If I comment out the initiation scripts for the staden package in  .bash_profile
dragging in bookmarks is OK.

Reproducible: Always

Steps to Reproduce:
0. ./firefox
1. click on bookmark this page
2. click on selected text within the "Name" field and try to drag.

OR

2. click on Bookmarks, then manage bookmarks
3. try to drag a bookmark.

Actual Results:  
Firefox crashes with message
./firefox-bin: relocation error:
/usr/local/staden_linux_2003.0b1/lib/linux-binaries/libpng12.so.0: undefined
symbol: inflateInit_


firefox start up errors were as follows:
downloads/firefox/firefox-bin:
/usr/local/staden_linux_2003.0b1/lib/linux-binaries/libstdc++.so.5: no version
information available (required by downloads/firefox/firefox-bin)

(repeated 5 times)


Expected Results:  
not crash.

This seems unlikely to be a problem for the majority of users, as it seems to be
caused by my library paths set up by another package.
However, it would be nice if firefox gave a warning or error message without
crashing.
if we're dying because we're expecting something to be stable in an external
library, that's a little hard to fix.  There's also the question of why our
builds are using system png in this case, normally we use our own.
Where did you get this build? If you type about:buildconfig in the urlbar, do
you see an entry --with-system-png or --without-system-png, and
--with-system-zlib or --without-system-zlib ?
(In reply to comment #2)
> Where did you get this build? 
from www.mozilla.org

>If you type about:buildconfig in the urlbar, do
> you see an entry --with-system-png or --without-system-png, and
> --with-system-zlib or --without-system-zlib ?
None of these entries are present. see attachment.
I'll check a more recent build to see if problem remains.
Severity: normal → critical
Keywords: crash
Sean:  Any luck reproducing with a recent build?  Also, it would be helpful if
you installed Firefox with Talkback enabled (Custom Install->Mozilla Quality
Feedback Agent) and submitted your crash reports.  You can look up the IDs by
running talkback.exe in your components directory...please post them here.
Hi all,

I have had another chance to look at this again with the latest build of firefox:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

The problem still persists, but is a problem with an external library rather
than firefox.

If I do:
$ export LD_LIBRARY_PATH="/usr/local/staden_linux_2003.0b1/lib/linux-binaries"
$ firefox

then firefox dies with the error 
./firefox-bin: relocation error:
/usr/local/staden_linux_2003.0b1/lib/linux-binaries/libpng12.so.0: undefined
symbol: inflateInit_
when it tries to display the page icon while dragging within the manage
bookmarks dialog.
Nothing comes up in the Mozilla quality feedback agent. I guess I have not got
this set up properly.


However if I do:
$ export LD_LIBRARY_PATH=""
$ firefox

everything is fine.
So I have been happily using recent firefox builds with LD_LIBRARY_PATH=""
for the past few months.
Whether you want to change firefox so it will never look at this environment
variable and attempt to use external libraries is up to you.

Sean
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → bookmarks
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: