142850 - Installation failed when installing 1.0 build on JA RH 7.1

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect, P1)

Description

[Rui Xu]

Build: 2002-05-06-15-1.0.0 and 2002-05-07-09-1.0.0
OS: JA RH 7.1

When installing 1.0 builds on JA RH 7.1, got the following error and the 
installation failed. 

Warning: MOZILLA_FIVE_HOME not set. 
./netscape-installer: line 45: 1583 segmentation violation.  
./netscape-installer-bin $@

Comment 1

[Doug Turner (:dougt)]

Rui Xu, can you get a stacktrace or talkback ID?

Shanjian, can you reproduce?

Comment 2

[Doug Turner (:dougt)]

rui, do you have space on your machine such that I can make a debug build?

Comment 3

[Rui Xu]

>> Rui Xu, can you get a stacktrace or talkback ID?
This happens on very early stage of installation, and talkback is not insatlled.

If using ./netscape-installer-bin with Blob installer, after extracting 
libplc4so..., got another error message: Fatal error [618]: Couldn't open 
xpistub library.

>> rui, do you have space on your machine such that I can make a debug build?
Yes, available space is 288828, how much do you want? 

Comment 4

[Jaime Rodriguez, Jr.]

--> syd, since dan is on vacation

Comment 5

[Syd Logan]

Is this happening in yesterday's build?

Comment 6

[Doug Turner (:dougt)]

Looks like it is crashing in the uconv dll.  no idea why yet..


#0  0x406dd4e6 in __jisx0212_from_ucs () from
/tmp/xpihH978Z/bin/components/libuconv.so
#1  0xbfffbbe0 in ?? ()
#2  0x406e0d50 in NSGetModule () from /tmp/xpihH978Z/bin/components/libuconv.so
#3  0x406e16d4 in NSGetModule () from /tmp/xpihH978Z/bin/components/libuconv.so
#4  0x406e17cb in NSGetModule () from /tmp/xpihH978Z/bin/components/libuconv.so
#5  0x406ddc05 in __jisx0212_from_ucs () from
/tmp/xpihH978Z/bin/components/libuconv.so
#6  0x40683271 in ?? ()
#7  0x40643c59 in ?? ()
#8  0x406445d1 in ?? ()
#9  0x4068477d in ?? ()
#10 0x406829a1 in ?? ()
#11 0x40638adb in ?? ()
#12 0x40638ca4 in ?? ()
#13 0x40638e7e in ?? ()
#14 0x4063911a in ?? ()
#15 0x4071c5df in NSGetModule () from /tmp/xpihH978Z/bin/components/libxpinstall.so
#16 0x40731fa4 in NSGetModule () from /tmp/xpihH978Z/bin/components/libxpinstall.so
#17 0x407726b2 in ?? ()
#18 0x407728fc in ?? ()
#19 0x40787c9c in ?? ()
#20 0x40786fb4 in ?? ()
#21 0x407769e3 in ?? ()
#22 0x40772aea in ?? ()
#23 0x40754945 in ?? ()
#24 0x407548f0 in ?? ()
#25 0x40754846 in ?? ()
#26 0x40724843 in NSGetModule () from /tmp/xpihH978Z/bin/components/libxpinstall.so
#27 0x4072446f in NSGetModule () from /tmp/xpihH978Z/bin/components/libxpinstall.so
#28 0x40723662 in NSGetModule () from /tmp/xpihH978Z/bin/components/libxpinstall.so
#29 0x4072312b in NSGetModule () from /tmp/xpihH978Z/bin/components/libxpinstall.so
#30 0x4052b74f in XPI_Install () from /tmp/xpihH978Z/bin/libxpistub.so
#31 0x0805c989 in nsXIEngine::InstallXPI () at eval.c:41
#32 0x0805c5e4 in nsXIEngine::Install () at eval.c:41
#33 0x08057e61 in nsInstallDlg::PerformInstall () at eval.c:41
#34 0x080570ed in nsInstallDlg::Next () at eval.c:41
#35 0x400b82b1 in gtk_marshal_NONE__NONE () at eval.c:41
#36 0x400eb916 in gtk_handlers_run () at eval.c:41
#37 0x400eac3d in gtk_signal_real_emit () at eval.c:41
#38 0x400e89f5 in gtk_signal_emit () at eval.c:41
#39 0x4004ff2d in gtk_button_clicked () at eval.c:41
#40 0x400516ed in gtk_real_button_released () at eval.c:41
#41 0x400b82b1 in gtk_marshal_NONE__NONE () at eval.c:41
#42 0x400eaac1 in gtk_signal_real_emit () at eval.c:41
#43 0x400e89f5 in gtk_signal_emit () at eval.c:41
#44 0x4004fe5d in gtk_button_released () at eval.c:41
#45 0x40050fd7 in gtk_button_button_release () at eval.c:41
#46 0x400b7fbc in gtk_marshal_BOOL__POINTER () at eval.c:41
#47 0x400eac7d in gtk_signal_real_emit () at eval.c:41
#48 0x400e89f5 in gtk_signal_emit () at eval.c:41
#49 0x401230e9 in gtk_widget_event () at eval.c:41
#50 0x400b7f15 in gtk_propagate_event () at eval.c:41
#51 0x400b6f3f in gtk_main_do_event () at eval.c:41
#52 0x4016ee4f in gdk_event_dispatch () at eval.c:41
#53 0x401a17f3 in g_main_dispatch () at eval.c:41
#54 0x401a1dd9 in g_main_iterate () at eval.c:41
#55 0x401a1f8c in g_main_run () at eval.c:41
#56 0x400b6803 in gtk_main () at eval.c:41
#57 0x0805aee2 in nsXInstaller::RunWizard () at eval.c:41
#58 0x0805b57b in main () at eval.c:41

Comment 7

[Syd Logan]

--> dprice. David, can you look into this? Has something to do with uconv, and I
wouldn't be suprised that yesterday's landing by dougt/samir may have some
impact. dougt should be able to help you.running yesterday's installer on the
same setup should help illuminate if the problem predated changes made yesterday
or not.

Comment 8

[Syd Logan]

--> dprice

Comment 9

[Rui Xu]

Also reproducible on RH 7.2.
Only see this with build 2002-05-06-15-1.0.0 and 2002-05-07-09-1.0.0.

If using English version RH, it is reproducible after changing locale settings 
(e.g. export LANG=ja_JP.eucjp).

Comment 10

[Doug Turner (:dougt)]

From sgehani:

nsXIEngine.cpp 689:
/u/sgehani/dev/linux/1.0/mozilla/installer/raw/./xpi/xpcom.xpi 
###!!! ASSERTION: failed to create encoder: '0', file nsUNIXCharset.cpp, line
369
###!!! Break: at file nsUNIXCharset.cpp, line 369
###!!! ASSERTION: unable to use nl_langinfo(CODESET): '0', file
nsUNIXCharset.cpp, line 293
###!!! Break: at file nsUNIXCharset.cpp, line 293
./mozilla-installer: line 52:  2171 Segmentation fault
./mozilla-installer-bin $@

Comment 11

[Doug Turner (:dougt)]

this problem did NOT occur prior to dveditz's changes.  Which makes sense since
we were not installing stuff via unicode.

shanjian, why would this above assertion be triggered?  Are we missing some
converter in the installer still?

these are the components that the installer is using...

libjar50.so  libuconv.so  libunicharutil.so  libxpinstall.so

Are we missing something?

Comment 12

[scottputterman]

adding to the beta stopper list.

Comment 13

[Shanjian Li]

Doug, those part of the code is used to get system charset. In the situation we
are talking about, it should find euc-jp to be the charset for locale
ja_JP.eucJP. I am wondering if this is because the property file (ie.
resource:/res/unixcharset." OSARCH ".properties) does not exist in this stage
yet, so we can't find out the charset and thus have this problem. 

A possible workaround is to set locale to be "C" in the script
"mozilla-installer" and restore it back after installation. Because if I am
right, the problem is very difficult to handle. 

Comment 14

[Frank Tang]

It looks like what happen is now the installer depend on the uconv to convert
between unicode and file system charset. But we have not install the converters
there yet. The reason the LANG = C work is because we do include the ISO-8859-1
converter in the uconv.dll but we didn't include the ucvja (and other converter)
before the code call it. 

Comment 15

[dprice (gone)]

This character conversion stuff is new to me.  How do we fix this?  Is it as
simple as linking  another .dll with the installer?

Comment 16

[Frank Tang]

dougt:
could you give me the stack trace when we hit
###!!! ASSERTION: failed to create encoder: '0', file nsUNIXCharset.cpp, line
369

Comment 17

[Shanjian Li]

As frank point out, the problem is most likely to be caused by the dependency of
conversion module. So moving following file to xpcom.xpi might also sounds like
an option for now. But I am not sure if we want to make xpcom.xpi that big. 
bin/components/libucvcn.so
bin/components/libucvibm.so
bin/components/libucvja.so
bin/components/libucvko.so
bin/components/libucvlatin.so
bin/components/libucvtw.so
bin/components/libucvtw2.so
bin/components/locale.xpt
bin/res/charsetalias.properties
bin/res/unixcharset.properties

I can't declare its completeness. We have to try them out if this option looks
reasonable. 

Comment 18

[Shanjian Li]

The other option is, if we can identify where conversion request is made and
avoid to make such request for unix, problem can also be solved. Of cause, we
will have the limitation of not being able to install onto a path that contains
native characters. But that limitation may not be a big deal since people rarely
use native path to install browser application anyway. If we allow people to
install it to native path, they may have problem running it from other locales.
If we can prompt users not to install it to native path, that should be good
enough. 

Comment 19

[Doug Turner (:dougt)]

for how to debug the installer:

http://www.mozilla.org/projects/xpinstall/wizard/unix/debugging.html

Comment 20

[Frank Tang]

ok, I have a quick fix, the fix will move 400K from browser.xpi to xpcom.xpi 

Comment 21

[Frank Tang]

Attachment: quick hack to fix the problem. move 400K from browser.xpi into xpcom.xpi

Comment 22

[Frank Tang]

I didn't try the patch directly. But what I test is in rui's machine, 
1) unzip the xpcom.xpi and browser.xpi into different directory
2) manually move the files above from browser directory to xpcom direoctry
3) zip them back to the new xpcom.xpi
4) and run it under the japanese locale, everything installed correctly.

Comment 23

[Doug Turner (:dougt)]

ftank... that will increase the download size by that much.... right?  

Can we break out the functionality needed cleaner?

Comment 24

[Frank Tang]

I have to go, can someone take the lead to get the patch r= / sr= and land it
into the branch ?
>ftank... that will increase the download size by that much.... right?  
no, it move the 400k from one xpi to another xpi.

Comment 25

[Frank Tang]

it increase 126 bytes of the sum of the size of browser.xpi and xpcom.xpi
before the patch, 
xpcom.xpi     801243
browser.xpi  8280284
together     9081527

after the patch
xpcom.xpi    1287322
browser.xpi  7794331
together     9081653

only 126 bytes differents

Comment 26

[dprice (gone)]

Will we need to make these changes in packages-static-unix?

Comment 27

[Sean Su]

dougt, it's just moving a file from one .xpi to another.  it's not going into
the stub file, so it should not be a problem.

dprice, yes.  it should be just a change in the packages-unix file (I don't know
about the static one, maybe).

Comment 28

[dprice (gone)]

I don't have a machine that can test this.  But I can give an r=dprice on the
patch  and work to get it checked in.

I do believe that we need to cover the static build as well.  Can someone make
and test a patch for the packages-static-unix ?

Comment 29

[Shanjian Li]

I could not identify components needed for static package, and I don't have
static build handy to test either. I guess this is because the conversion module
are staticly linked to browser. If that is the case, we will have some
difficulty here. We might want to use other options (as I mentioned in this bug
before). But anyway we do not want to hold this patch for static build. 

Comment 30

[dprice (gone)]

Comment on attachment 82743 [details] [diff] [review]
quick hack to fix the problem. move 400K from browser.xpi into xpcom.xpi

r=dprice

Comment 31

[dprice (gone)]

I'm cool with fixing the dynamic build and filing a separate bug to take care of
the static install.  I've asked rjesup to comment on the importance of the
static build. 

Comment 32

[Jaime Rodriguez, Jr.]

alec/mscott - is this a patch you can sr=?

Comment 33

[scottputterman]

Dave, do you have someone lined up as a super reviewer? If not, could you mail
[e-mail] to find one?

Comment 34

[jag (Peter Annema)]

Comment on attachment 82743 [details] [diff] [review]
quick hack to fix the problem. move 400K from browser.xpi into xpcom.xpi

sr=jag

Comment 35

[dprice (gone)]

have the sr= from jar adding adt1.0.0

Comment 36

[scottputterman]

adding adt1.0.0+.  You still need drivers approval.  Once you get that, please
check this into the branch.

Comment 37

[Daniel (Leaf) Nunes]

a=leaf on behalf of [e-mail]

Comment 38

[Sean Su]

patch checked into the branch only for dprice.  closing bug.  thanks leaf!

Comment 39

[Randell Jesup [:jesup] (needinfo me)]

dprice asked me: Can you comment on the importance of fixing the static build as
well?

I'm not a static-build guru, though we do use it and I am conversant with how
linkers & loaders work.

No changes are needed for packages-static-unix because all the ucv* converters
are staticly linked into the binary.

Comment 40

[Frank Tang]

you may need the following file for the static build in xpcom.xpi
+bin/res/unixcharset.properties

Comment 41

[Rui Xu]

Tried on the following locales:

1. It is not reproducible on the following locales:
   ja_JP.eucJP
   zh_CN.GB2312
   ko_KR.euckr
   korean.euc

2. Still see the same problem on the following locales:
   ja_JP.SJIS
   zh_TW.Big5

Comment 42

[Frank Tang]

I think we should not hold beta against 
   ja_JP.SJIS
   zh_TW.Big5

because we won't release beta in sjis nor big5 locale.
for people using that two locale, they can work around by adding LANG=en_US
before calling the installer. We need to release note that thought. 
shanjian, please dig into it. We need to support sjis locale later for HP port

Comment 43

[Shanjian Li]

Ruixu, could you file a new bug and close this one? The problem seems to be a
different issue. On RH7.2, nl_langinfo(CODESET) returns "ANSI_X3.4-1968" as
charset, that is an alias of us-ascii. I guess this trigger the problem. On HP,
it does not have this problem.  So the problem won't happen on HP.

Comment 44

[Rui Xu]

As per Comment #43, filed a separate bug 143132 (Installation failed when 
installing under some locales).

Comment 45

[Asa Dotzler [:asa]]

Comment on attachment 82743 [details] [diff] [review]
quick hack to fix the problem. move 400K from browser.xpi into xpcom.xpi

a=asa (on behalf of drivers) for checkin to the 1.0 branch

Comment 46

[Paul Wyskoczka]

Marina, could you see if this is fixed on the trunk. Thx.

Comment 47

[Teruko Kobayashi]

I could not reproduce this problem with 06-06 1.4branch and 06-06-11 trunk Linux
build on JA RH  7.1, ja_JP.eucJP locale.