Installing New Themes not possible, leads to a crash

VERIFIED FIXED in mozilla1.0

Status

SeaMonkey
Themes
P2
critical
VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: Carsten Menke, Assigned: hacker formerly known as seawood@netscape.com)

Tracking

({crash})

Trunk
mozilla1.0
x86
Linux
crash

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [static build] [WGATE])

Attachments

(2 attachments, 4 obsolete attachments)

(Reporter)

Description

17 years ago
Go to View->Apply Themes->Get New Themes, now take any theme you want from
xulplanet, as soon as you hit the Install Now link, Mozilla Crashes.

This happened with the Build from Feb 2nd until today's build Feb 23th 2002.
Build System:
Mandrake 8.0 gcc-2.95.3 glib-2.2.2, gtk-1.2.10 Kernel: 2.4.8-ac7

Build Options:
ac_add_options --prefix=/usr/lib/mozilla-097
ac_add_options --libdir=/usr/lib/mozilla-097
ac_add_options --includedir=/usr/include/mozilla-097
ac_add_options --enable-crypto
ac_add_options --disable-accessibility
ac_add_options --enable-mathml
ac_add_options --enable-svg
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --enable-optimize="-O6 -march=i686 -mcpu=i686"
ac_add_options --disable-dtd-debug
ac_add_options --enable-strip
ac_add_options --with-default-mozilla-five-home=/usr/lib/mozilla-097
ac_add_options --with-user-appdir=".mozilla-098"
ac_add_options --enable-static
ac_add_options --disable-shared

I bet that this is directly related to bug 119450, and fixing that bug would
also fix this bug. I marked this blocker, due to that this both things are not
working I could not imagine that this should go into 0.99

GDB Output Attached
(Reporter)

Comment 1

17 years ago
Created attachment 71093 [details]
GDB Output
(Reporter)

Updated

17 years ago
Keywords: crash, mozilla0.9.9
Target Milestone: --- → mozilla0.9.9

Comment 2

17 years ago
WFM 2002022203/WinXP
wfm with win2k 20020223..
Severity: blocker → critical
Target Milestone: mozilla0.9.9 → ---
(Reporter)

Comment 4

17 years ago
Hmmh, intersting because it works on Win32 it is not a blocker ?

Comment 5

17 years ago
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020222
WFM.  This is not a blocker because it does not block Mozilla development.

Do you crash on all themes?  Have you tried installing other xpi packages
(stacktrace shows you are in xpinstall)?
(Reporter)

Comment 6

17 years ago
Yes all themes I tried lead to a crash, also using:
Edit->Preferences->Appearance->Content/Language Packs->Download More

to install a new Language Pack leads to a crash. Give me some links, I should
try and I will attach a gdb for each.
Confirmed the crash using the build options posted.  Also confirmed it without
the optimize flags & without the strip option.  The trace looks similar to what
Carsten attached.  
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [static build]

Comment 8

16 years ago
I get the same crash when trying to install any theme from the "View->Apply
Themes->Get New Themes" page. OpenVMS (static build based on Linux), 1.0-rc1.

Comment 9

16 years ago
This appears to be a static build problem. Shouldn't Seawood be in on this? 
Taking the liberty of cc'ing him.

This might have something to do with the fact that libxpinstall.so has its own 
copy of the javascript code (libmozjs). Looking at the call frames you can see 
javascript routines from both the main mozilla image and libxpinstall.so being 
invoked. Something's then getting very confused.

There's a comment in libxpinstall's Makefile saying that it has to be built 
shared, even for static builds, because its used by the installer. So does 
libmozjs also need to be built shared?

Comment 10

16 years ago
Created attachment 82625 [details] [diff] [review]
Build mozjs shared, even on a static build

JavaScript must be built shared, even for static builds, as it is used by other
modules which are always built shared. Failure to do so results in the js code
getting copied into xpinstall and jsd as well as mozilla-bin, and then the
static data cells used for locking no longer work.

Attaching patch. Can we get this into RC2?
Comment on attachment 82625 [details] [diff] [review]
Build mozjs shared, even on a static build

r=rjesup@wgate.com

This is definitely safe to do, and appears to be the issue here (while there
might be better ways to solve shared/static dependencies like this in the
future, they're much more complex).  We still want r/sr=seawood before approval
can be given.
Attachment #82625 - Flags: review+
*** Bug 119450 has been marked as a duplicate of this bug. ***
Reassigning to patch owner (I volunteer to check it in if needed).

This is a wgate issue (we use static build - big perf win).

CC'ing some JS/xpcom people.  Looking for sr (especially from seawood) and then
approval.
Assignee: hewitt → colin
Keywords: mozilla0.9.9 → mozilla1.0, patch
Whiteboard: [static build] → [static build] [WGATE]

Comment 14

16 years ago
Created attachment 82900 [details] [diff] [review]
Revised patch with EXPORT_LIBRARY removed

I just completed a full clean build and with the previous patch the link of
mozilla-bin was still looking for libmozjs.a. This is because EXPORT_LIBRARY
was set in mozjs's Makefile. So the second version of the patch removes
EXPORT_LIBRARY. Now mozilla-bin links.
Attachment #82625 - Attachment is obsolete: true

Comment 15

16 years ago
Created attachment 82902 [details] [diff] [review]
Make embedding tests link too

The GTK embedding tests now need to link with MOZ_JS_LIBS since the js code is
no longer in a static lib. Hopefully this is the final version of the patch.
Attachment #82900 - Attachment is obsolete: true

Comment 16

16 years ago
Created attachment 82908 [details] [diff] [review]
MOZ_JS_LIBS for mozilla-bin static link

mozilla-bin now needs MOZ_JS_LIBS for both static and shared libs.
Attachment #82902 - Attachment is obsolete: true
Added to RC3 buglist as per shaver and Asa
Blocks: 143200
Comment on attachment 82908 [details] [diff] [review]
MOZ_JS_LIBS for mozilla-bin static link

We should be using FORCE_SHARED_LIBS (as we do for win32) rather than
redefining  BUILD_STATIC_LIBS & BUILD_SHARED_LIBS.  Also, because JS requires
NSPR in cross compiled builds, we should be linking JS before NSPR.
Attachment #82908 - Flags: needs-work+
Just a thought: are we going to run into a similar problem with our other
application level libs that are also linked into some components (gfx, jsj,
etc)?  Should we only be linking the components statically?  If so, I need to
rename the configure option has it's a huge misnomer.
Created attachment 83305 [details] [diff] [review]
Use FORCE_SHARED_LIB, reorder link decl & update static packaging
Attachment #82908 - Attachment is obsolete: true

Comment 21

16 years ago
> Are we going to run into a similar problem with our other application
> level libs

Anything which has static data and is linked into more than one shared library 
(or linked into one shared library and mozilla-bin) is busted, I think.

Comment 22

16 years ago
do we need to address this in windows static build too?
Cathleen: This particular problem? No. Win32 was already building js dynamically
in static builds. 

Comment 24

16 years ago
lets get reivew going.
Whiteboard: [static build] [WGATE] → [static build] [WGATE] need review
Comment on attachment 83305 [details] [diff] [review]
Use FORCE_SHARED_LIB, reorder link decl & update static packaging

r=bryner
Attachment #83305 - Flags: review+
Patch has been checked into the trunk.
Blocks: 138348
Whiteboard: [static build] [WGATE] need review → [static build] [WGATE] [fixed on trunk]

Comment 27

16 years ago
we need an sr on this. drivers wants to take this for rc3. It will need to be
checked in to the branch by thursday pm.

Comment 28

16 years ago
Reassigning to (correct) patch owner. Thanks for the right fix, Chris!
Assignee: colin → seawood
Keywords: patch
Priority: -- → P2
Target Milestone: --- → mozilla1.0

Comment 29

16 years ago
Comment on attachment 83305 [details] [diff] [review]
Use FORCE_SHARED_LIB, reorder link decl & update static packaging

a=chofmann for the 1.0 branch
Attachment #83305 - Flags: approval+

Comment 30

16 years ago
seawood, can you check this in asap to get in for 1.0?
The patch has been checked into the moz1.0.0 branch.
Keywords: fixed1.0.0
Whiteboard: [static build] [WGATE] [fixed on trunk] → [static build] [WGATE]
fixed.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Updated

16 years ago
No longer blocks: 143200

Comment 33

16 years ago
Verified on linux redhat 7.3 (netscape trunk build: 2002-11-18-08-TRUNK), and
netscape branch build (2002-11-14-07-1.0)
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.