Closed Bug 209048 Opened 21 years ago Closed 21 years ago

recent mozilla build corrupt the .mozilla folder on shutdown (2003061100)

Categories

(Core Graveyard :: Profile: BackEnd, defect)

Product:
Core Graveyard
Component:
Profile: BackEnd
Platform:
Sun
Solaris
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bobsomerville, Assigned: jshin1987)

References

Details

(Keywords: relnote, Whiteboard: Bug in Solaris, please apply Solaris patch 112689-02 (or higher) to cure it)

Attachments

(7 files)

an iconv test program
1.60 KB, text/plain
Details
my ico4.c
1.50 KB, text/plain
Details
a barebone version of nsNAtiveCharsetUtils.cpp
16.98 KB, text/plain
Details
two test files for iconv
202 bytes, application/x-gzip
Details
jpeg
92.97 KB, image/jpeg
Details
jpeg
97.02 KB, image/jpeg
Details
another redone jpeg
83.74 KB, image/jpeg
Details 
User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.5a) Gecko/20030602
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.5a) Gecko/20030602

if I start up a recent build, mozilla comes up OKAY,if I shutdown and restart up
Mozilla, it wants to migrate my old NETSCAPE4 setup, or wants me to select another
user, won't let me use the correct one. recovering my previous .mozilla
directory from backup solves the problem

Sun solaris 7 on ultra sparc 1, gcc 3.2.3

Reproducible: Always

Steps to Reproduce:
1.
2.see details
3.



Expected Results:  
not corrupted the ,mozilla directory
Works fine for me on Solaris 8/9 with us3 and gcc 2.95.3 and moz cvs 20030611
bz:
Is it possible that the checkin for "Mozilla does not work on NFS filesystems"
caused this issue ?
OS: SunOS → Solaris
No clue.  jshin, could this be related to the iconv() stuff?

Robert, any chance you could test some builds going back a few days and see
whether this is a problem with them?  (eg test June 9, June 7, etc.)
June 9 definatly fails, june 02 works, i will investigate further:

P.S. i am running Mozilla on a machine (on the local network) other than my own,
sending display back to my machine; .mozilla directory is on my machine ( RE
question about NFS ?? )
my June 09 build fails(corrupts) when run both remotely & localy !
your June 07 build also fails
my june 02 build works okay

if somebody can help me navigate the mozilla ftp server, and point me to
builds between 02 & 07, i would be happy to test them (P.S. a CVS build pretty
much takes up all night, so i would like to avoid the CVS route)
> Is it possible that the checkin for "Mozilla does not work on NFS filesystems"
caused this issue ?

Unlikely, since the only case that was changed by that fix was specific to
XP_MACOSX.

Can you clarify waht's happening here? What is actually "corrupted?"

> or wants me to select another user, won't let me use the correct one

Does it say that it's in use? If so, are you sure that no other copy of mozilla
is running?
Component: Browser-General → Profile Manager BackEnd
>
>Can you clarify waht's happening here? What is actually "corrupted?"
>

sorry; I have no idea, but is related to something _REALLY_BAD_ happening in
.mozilla directory with recent builds. i am just a MOZILLA user ;-(  {  a
programmer developer by profession , (and i don't do C++)  }

if you gave me some files to watch in that directory, i could do that !

>> or wants me to select another user, won't let me use the correct one
>
>Does it say that it's in use? If so, are you sure that no other copy of mozilla
>is running?

Possitively no other mozilla running !!
This problem started sometime after 02 june , and continues with my build of
this AM ,june 11

 I had to rebuild my .mozilla directory from _ZERO_ on or about June_06 due to
this problem ( not pleasant, perhaps i could have saved all my email if i had
been more carefull :-(   )


IN MORE DETAIL:

> Can you clarify waht's happening here? What is actually "corrupted?"

1) i start up Mozilla after problem has happened.
2) it asks me to select a profile (only one availaible "rsomerv"), i dont't
expect to see this popup any-ways
3) i select "rsomerv" ( that's my profile" )
4) I get an error message popup saying:

"mozilla cannot use the profile "rsomerv" because the directory containing the
profile cannot be found ...... etc"

here is an ls of .mozilla right afterwards:
[redwood]{441}[.mozilla.old2]: ll
total 1505
-rw-rw-rw-    1 rsomerv  pgldev       1219 Dec 12  2001 mozver.dat
drwxrwxrwx    2 rsomerv  pgldev        512 Dec 12  2001 rsomerv2/
-rwxr-xr-x    1 rsomerv  pgldev    1145171 May 17  2002 libflashplayer.so*
-rw-r--r--    1 rsomerv  pgldev       2363 May 17  2002 ShockwaveFlash.class
-rw-rw-rw-    1 rsomerv  pgldev     104780 Aug 28  2002 x.x
drwxrwxr-x    3 rsomerv  pgldev        512 Aug 29  2002 Default User/
-rw-rw-rw-    1 rsomerv  pgldev     105946 Sep 13  2002 appreg.back
drwxrwxrwx    2 rsomerv  pgldev        512 Mar  5 10:07 plugins/
drwxrwxr-x    3 rsomerv  pgldev        512 Jun  5 08:38 rsomerv/
drwxrwxr-x    6 rsomerv  pgldev        512 Jun 11 08:38 ./
-rw-rw-rw-    1 rsomerv  pgldev     107868 Jun 11 15:16 appreg
-rw-------    1 rsomerv  pgldev         65 Jun 11 15:16 pluginreg.dat
drwxrwxrwx   65 rsomerv  develope    22016 Jun 11 15:18 ../

here is ls of ./rsomerv :
[redwood]{443}[rsomerv]: ll
total 3
drwxrwxr-x    3 rsomerv  pgldev        512 Jun  5 08:38 ./
drwxrwxr-x    6 rsomerv  pgldev        512 Jun 11 08:38 ../
drwxrwxr-x    6 rsomerv  pgldev       1024 Jun 11 15:16 heonx2q6.slt/

[redwood]{445}[heonx2q6.slt]: ll
total 2774
drwxrwxr-x    3 rsomerv  pgldev        512 Jun  5 08:38 ../
-rw-r--r--    1 rsomerv  pgldev       2335 Jun  5 08:38 search.rdf
-rw-r--r--    1 rsomerv  pgldev       2169 Jun  5 08:38 panels.rdf
-rw-r--r--    1 rsomerv  pgldev       2623 Jun  5 08:38 mimeTypes.rdf
-rw-rw-rw-    1 rsomerv  pgldev       1395 Jun  5 08:41 history.mab
-rw-------    1 rsomerv  pgldev      32768 Jun  5 08:42 secmod.db
-rw-r--r--    1 rsomerv  pgldev        477 Jun  5 08:46 mailViews.dat
drwxrwxr-x    6 rsomerv  pgldev        512 Jun  5 08:54 Mail/
-rw-rw-rw-    1 rsomerv  pgldev      17592 Jun  5 09:12 impab-1.mab
-rw-rw-rw-    1 rsomerv  pgldev      13867 Jun  5 09:12 impab-2.mab
-rw-r--r--    1 rsomerv  pgldev    1107590 Jun  5 09:59 XUL.mfasl.bob
drwxrwxrwx    3 rsomerv  pgldev        512 Jun  5 16:01 chrome/
-rw-rw-rw-    1 rsomerv  pgldev      40229 Jun  6 14:51 impab.mab
-rw-rw-rw-    1 rsomerv  pgldev        655 Jun  6 14:53 downloads.rdf
drwxrwxrwx    2 rsomerv  pgldev        512 Jun  7 20:00 Cache.Trash/
-rw-------    1 rsomerv  pgldev      72485 Jun 11 11:50 bookmarks.htm
-rw-rw-rw-    1 rsomerv  pgldev        451 Jun 11 14:40 54824411.s
-rw-rw-rw-    1 rsomerv  pgldev      21482 Jun 11 14:44 training.dat
drwxrwxrwx    2 rsomerv  pgldev       4096 Jun 11 15:15 Cache/
-rw-rw-r--    1 rsomerv  pgldev       8627 Jun 11 15:15 cookies.txt
-rw-------    1 rsomerv  pgldev      65536 Jun 11 15:15 cert8.db
-rw-------    1 rsomerv  pgldev      32768 Jun 11 15:15 key3.db
-rw-rw-rw-    1 rsomerv  pgldev     109106 Jun 11 15:15 history.dat
-rw-------    1 rsomerv  pgldev      72575 Jun 11 15:15 bookmarks.html
-rw-r--r--    1 rsomerv  pgldev    1112608 Jun 11 15:15 XUL.mfasl
-rw-rw-r--    1 rsomerv  pgldev      12073 Jun 11 15:16 prefs.bak
-rw-rw-r--    1 rsomerv  pgldev      12073 Jun 11 15:16 prefs.js
-rw-rw-rw-    1 rsomerv  pgldev      25404 Jun 11 15:16 localstore.rdf
-rw-rw-rw-    1 rsomerv  pgldev       5134 Jun 11 15:16 panacea.dat
drwxrwxr-x    6 rsomerv  pgldev       1024 Jun 11 15:16 ./
-rw-rw-rw-    1 rsomerv  pgldev      11768 Jun 11 15:16 abook.mab


anything else that you would like ???


Robert, could you do a before/after diff or the "appreg" file when running with
a broken build and starting with a working profile?

There are no builds prior to June 7 up on the FTP server, unfortunately; I
really wish we kept archives... :(

If you do get a chance to compile a build, pulling by date for the evening of
June 3rd would be a good place to start (I suspect that the build you get will
be broken....)
whoops - changed component but didn't reassign to myself.

> because the directory containing the profile cannot be found

Certainly not a symptom of a profile locking problem, as suggested in comment 2
- we can't get that far if the profile directory can't be found to begin with.

It does sound like something is wrong with appreg.
Assignee: general → ccarlen
QA Contact: general → gbush
Attached file an iconv test program — 
> jshin, could this be related to the iconv() stuff?

As far as Solaris on Sparc (ix86 should not be a problem, either because
according to Masaki, it's native-endian. bug 208809 comment 13) is concerned,
it's hard to  see how it can break things that way unless iconv(3) does
something unexpected with UTF-16. 

Robert, can you do the following two tests?

1. run this program on your machine (after compiling it to 'ico4'. You have to
replace '(char **)' with '(const char **)' in line 46? because iconv(3) in
Solaris expects the 2nd arg. to be 'const char **' ) ? 

  $ ico4 UCS-2 UTF-8
  $ ico4 UTF-16 UTF-8

2. a. back up your ~/.mozilla directory
   b. reverse the patch (attachment 124092 [details] [diff] [review] to bug 206811) 
   c.  recompile xpcom/ 
   d. run mozilla again
 
BTW, what is your version of Solaris ('uname -a')? The only Solaris I can
access is 2.7 (Sun OS 5.7) and I got segfault :

Program received signal SIGSEGV, Segmentation fault.
0xff360a64 in __icv_iconv () from /usr/lib/iconv/UTF-16%UTF-8.so
Roland and Masaki, do you have any profile-related problem on Solaris with a
recent build (post June 3rd)? I don't want you to lose your profile. Please,
back up ~/.mozilla before testing :-)
Attached file my ico4.c — 
my modifications to ico4
ANSWER to question #1 follows: 

[spruce]{498}[rsomerv]: gcc ico4.c -o ico4
[spruce]{499}[rsomerv]: ./ico4 UCS-2 UTF-8
Segmentation fault
[spruce]{500}[rsomerv]: ./ico4 UTF-16 UTF-8
Segmentation fault
****************************
[spruce]{505}[bob]: gcc --version
gcc (GCC) 3.2.3
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 *************************
[spruce]{512}[rsomerv]: uname -a
SunOS spruce 5.7 Generic_106541-23 sun4u sparc SUNW,Ultra-4
 *************************
my next step: unless somebody tells me different is to CVS pull june03, and test
it with & without XPCOM patch ( if it fails ) ,don't hold your breath waiting
for a result  ;-(      ( maybe later today )
Regarding APPREG:

find ./ -name "*appr*" -ls
634746  120 -rw-rw-rw-   1 rsomerv  pgldev     107868 Jun 12 06:01 ./appreg.bob
635106  120 -rw-rw-rw-   1 rsomerv  pgldev     107868 Jun 12 06:22
./appreg.bad_before_death
635103  120 -rw-rw-rw-   1 rsomerv  pgldev     107868 Jun 12 06:24
./appreg.bad_after_death

SO:
1) appreg.bob was appreg from stable MOZILLA ( June02 )
2) appreg.bad_before_death was appreg from JUNE09 during first run of it
3) appreg.bad_after_death was appreg from JUNE09 after 2nd run of it (and death
of Mozilla )

[redwood]{436}[.mozilla]: diff appreg.bad_after_death appreg.bad_before_death
Binary files appreg.bad_after_death and appreg.bad_before_death differ
[redwood]{438}[.mozilla]: diff appreg.bob appreg.bad_before_death
Binary files appreg.bob and appreg.bad_before_death differ
[redwood]{439}[.mozilla]: diff appreg.bob appreg.bad_after_death
Binary files appreg.bob and appreg.bad_after_death differ




I missed the comment in xpcom/io/nsNativeCharsetUtils.cpp that reads 'Evil 
Solaris crashes.....'. I'm not supposed to invoke iconv(3) with 4 NULL's under 
Solaris.  
 
After replacing 'iconv (icd, NULL, NULL, NULL, NULL) with the equivalent but a 
safe alternative in nsNativeCharsetUtils.cpp, I was able to run through the 
test. As Masaki told me, under Solaris 2.7 (Sun OS 5.7), UCS-2 and UTF-16 gave 
exactly the same result(as far as BMP is concerned)  , which positively 
removes my utf-16/iconv patch from the list of culprits for this bug.  as bz 
told me off-line.
Flags: blocking1.4?
RE test program: Just in case somebody was interested:

It works fine on an SGI r10000: ( same endian sense )
******************************************
[o2000]{402}[rsomerv]: ./ico5 UCS-2 UTF-8
inlen=2, in= 20 21       outlen=3, out= e2 80 a1
inlen=4, in= ff fe 20 21 outlen=6, out= ef bb bf e2 84 a0
inlen=4, in= fe ff 20 21 outlen=6, out= ef bb bf e2 80 a1
[o2000]{403}[rsomerv]: ./ico5 UTF-16 UTF-8
inlen=2, in= 20 21       outlen=3, out= e2 80 a1
inlen=4, in= ff fe 20 21 outlen=6, out= ef bb bf e2 84 a0
inlen=4, in= fe ff 20 21 outlen=6, out= ef bb bf e2 80 a1

Need immediate NEWBIE CVS help:

Something that I am doing is blowing away (at least) the direcories:

./mozilla/security/nss &
./mozilla/security/coreconf

when i do this ( I believe ) :
gmake -f ./client.mk MOZ_CO_FLAGS="-PA -D'2003-06-04 00:00'"

I'm really trying :-(  , sorry guys
Robert, just put:

mk_add_options MOZ_CO_DATE="2003-06-04 00:00"

(though you may need to watch out for timezones... the CVS server is in Pacific
time) to your .mozconfig file in the mozilla source directory (same dir where
client.mk is).

Then do:

gmake -f client.mk checkout

and it will pull from the right date.

I suspect the problem with what you are doing is that NSS is pulled by tag, so
when you update it with -PA things get broken.

Thanks for taking the time to help debug this...
RE CVS build:

I finally seem to be have a running build process :-)
Thanks for your help Boris ;-)

It would be great if there were more documentation on the Mozilla web
site on the more obscure build options that one might want to use , for us
NEWBIES. I suspect  the only way I could have found the mk_add_options is
"finding" & "greping" thru the Mozilla source tree, or was i being blind ??


Robert, http://webtools.mozilla.org/build/config.cgi is linked from the "Unix
Build Instructions" page...
RE MOZILLA SPARC BUILD of JUNE04 - 01:00 MST CVS PULL :

Its NO good !!!!!

p.s. backing up Mail-boxs, appreg, XUL* , bookmarks, and *.mab , recovers my
installation fine ( I think, so far  )
PROBLEMS with reversing the Patch:

[spruce]{650}[io]: patch -p2 < pat
patching file nsNativeCharsetUtils.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n] y
Hunk #3 FAILED at 174.
1 out of 8 hunks FAILED -- saving rejects to file nsNativeCharsetUtils.cpp.rej

gmake[1]: Entering directory `/spruce2/bob/mozilla/xpcom/io'
nsNativeCharsetUtils.cpp
g++ -o nsNativeCharsetUtils.o -c -DOSTYPE=\"SunOS5\" -DOSARCH=\"SunOS\"
-D_IMPL_NS_COM         -I../../dist/include/string -I../../dist/include/xpcom
-I../../dist/include -I/home/sp       ruce2/bob/mozilla/dist/include/nspr    
-I/usr/openwin/include   -fPIC  -I/usr/openwin/       include -fno-rtti
-fno-exceptions -pedantic -Wno-long-long -Os -mcpu=v9 -mtune=v9 -fsho      
rt-wchar -pthreads  -DNDEBUG -DTRIMMED  -I/usr/openwin/include -DMOZILLA_CLIENT
-includ       e ../../mozilla-config.h -Wp,-MD,.deps/nsNativeCharsetUtils.pp
nsNativeCharsetUtils.cpp
nsNativeCharsetUtils.cpp: In static member function `static void 
   nsNativeCharsetConverter::LazyInit()':
nsNativeCharsetUtils.cpp:274: `UCS_2_NAMES' undeclared (first use this 
   function)
nsNativeCharsetUtils.cpp:274: (Each undeclared identifier is reported only once 
   for each function it appears in.)
gmake[1]: *** [nsNativeCharsetUtils.o] Error 1
gmake[1]: Leaving directory `/spruce2/bob/mozilla/xpcom/io'
gmake: *** [all] Error 2

PATCH.REJECT:::

***************                                                                
              *** 175,187 ****                                                 
                                  return INVALID_ICONV_T;
  }                                                                            
                                                                               
                            - // PRUnichar[] is NOT a UCS-2 array BUT for UTF-16
string. Therefore, we
- // have to use UTF-16 with iconv(3) on platforms where it's supported.       
              - // We could list 'UTF-16' name variants, but all platforms known
(to me) to                 - // support UTF-16 in iconv(3) uses 'UTF-16'. Let me
(jshin) if there's an
- // exception.                                                                
              - static const char *UTF_16_NAMES[] = {                          
                            -     "UTF-16",
      "UCS-2",
      "UCS2",
      "UCS_2",
--- 174,180 ----
      return INVALID_ICONV_T;                                                  
                }                                                              
                                                                               
                                          + static const char *UCS_2_NAMES[] = {
                                                             "UCS-2",          
                                                                           "UCS2",
      "UCS_2",

For Solaris, the only change by that patch is one additional entry ("UTF-16") in
UCS_2_NAMES[] plus the name change (UCS_2_NAMES[] -> UTF_16_NAMES[]) which is 
where the reverse patch got rejected because I changed the indentation/wording
slightly when landing the patch. Anyway, you can just manually revert them.  

1. UTF_16_NAMES[] -> UCS_2_NAMES[] 
2. remove "UTF-16" at the top in the array

However, I don't think this will make any difference judging from the iconv test
result. 
RE nsNativeCharsetUtils.cpp & JUNE04 CVS PULL & BUILD;

i rebuilt Mozilla the same as last time (no CVS PULL) , except i replaced the
current nsNativeCharsetUtils.cpp with the one dated Mar21; and
_THE_BUILD_IS_GOOD_ !!

[spruce]{781}[io]: ll  nsNativeCharsetUtils.cpp
-rw-r--r--    1 rsomerv  pgldev      38446 Mar 21 15:24 nsNativeCharsetUtils.cpp

As a geophysical programmer with >15 years experience; think it possible
to say something appears to be wrong with nsNativeCharsetUtils.cpp

i am currently pulling Mozilla source for JUNE03 01:00 Mountain time, and will
let you know results on Monday !!
That's really strange. Before you go off for the weekend, can you try 
attachment 125288 [details] (to bug  208809)  and let me know the result? As far as
Solaris is concerned, the only change brought in by my patch is UCS-2 -> UTF-16
Could you also do the test in bug 208809 comment #8? I'll also do that under
Solaris 2.7(Sun OS 5.7 : the same as yours), but to make sure I'd like you to do
that as well.

I did the test I asked Robert to do under Solaris 2.7(Sun OS 5.7) and I didn't 
find anything unexpected. Solaris iconv(3) doesn't support all combinations of 
a <-> b conversions so that we have to convert by way of UTF-8, but that's 
well known and taken care of by the current code. 

I have no clue why Robert obtained the result in comment #22 and comment #25.

Next test may be to pull out a part of nsNativeCharsetUtils.cpp, compile it by 
itself and see how it goes. 
 
This is a stripped-down version of nsNativeCharsetUtils.cpp.
With this program, I tried to emulate what happens at Mozilla's start-up. 
Under Solaris, it has to be compiled with '-DICOCONST' given
at the command line.  
Robert, can you try this program after compiling 
( g++ -DICOCONST -o ico5 ico5.cpp )? 
Type a random string and [return] and you'll get sth. like this :

$ ./ico5 
abcd123
native string = abcd123
native string =  61 62 63 64 31 32 33
native string length = 7
native string left = 0
unicode string length = 7
unicode string =  0061 0062 0063 0064 0031 0032 0033
unicode string left = 0
native string = abcd123
native string =  61 62 63 64 31 32 33
native string length = 7

I tried this under Solaris 2.7 and couldn't find anything unusual.
I also ran it	under fr, de_DE.ISO8859-15, en_US.UTF-8, sv.UTF-8
locales.  Characters like  'U+00C0' and  'U+00D0' are converted
to and from Mozilla's Unicode (UTF-16) without any problem under
fr and de_DE.ISO8859-15. Under en_US.UTF-8 and sv.UTF-8 locale, 
characters like 'U+AC00' presented no problem. 

This result made it even harder to understand what's reported in
comment #22 and comment #25.
Here's my results for ICO6:

P.S. my CVS PULL/BUILD for june03 failed due to sort of finger problem, will try
again today:

[spruce]{808}[rsomerv]:  g++ -DICOCONST -o ico5 ico6.cpp
[spruce]{809}[rsomerv]: ./ico5 
abcd123
native string = abcd123
native string =  61 62 63 64 31 32 33
native string length = 7
native string left = 0
unicode string length = 7
unicode string =  0061 0062 0063 0064 0031 0032 0033
unicode string left = 0
native string = abcd123
native string =  61 62 63 64 31 32 33
native string length = 7

I thought i would include a second run that was different from yours :-)


[spruce]{830}[rsomerv]: ./ico5
567834xtvg        
native string = 567834xtvg
native string =  35 36 37 38 33 34 78 74 76 67
native string length = 10
native string left = 0
unicode string length = 10
unicode string =  0035 0036 0037 0038 0033 0034 0078 0074 0076 0067
unicode string left = 0
native string = 567834xtvg
native string =  35 36 37 38 33 34 78 74 76 67
native string length = 10

There's absolutely nothing wrong with both results. This makes even more
strange your results in comment #22 and comment #25. 
Is there anyone else with this problem under Solaris 2.7? 

I'm attaching icotest.tar.gz with ico.88591 and ico.utf8. This is not much
relevant, but just in case (actually I've already tested them under Solaris 2.7
and both gave me expected results)

$ LC_ALL=en_US.UTF-8 ./ico6 < ico.utf8
$ LC_ALL=fr	      ./ico6 < ico.utf8
$ LC_ALL=C	       ./ico6 < ico.utf8

$ LC_ALL=fr	     ./ico6 < ico.88591
$ LC_ALL=C	      ./ico6 < ico.88591
$ LC_ALL=en_US.UTF-8 ./ico6 < ico.88591
Latest test:

I pulled june02 12:00 MST, build is good:
I will try june03 00:00 next

if there is any (partial) patch you wish me to try, please let me know :-) 

jshin, should you take this bug? It doesn't appear to be a profile mgr bug -
profile mgr is just first to get hit by it.
Attached image jpeg — 
latest results from iconv:
Attached image jpeg — 
redone jpegs, sorry i didn't read instructions clearly
Attached image another redone jpeg — 

    
    

    
  
Latest test:

I pulled june03 00:00 MST, build is good:
I will try june03 08:00 MST next



    
    

    
  
Conrad, despite the test result in comment #22 and comment #25, 
I'm not yet sure that nsNativeCharsetUtils.cpp change caused this bug because
all other stand-alone test results are negative.  

Anyway, let me assign this to myself for now. (I can't spend much time on
Mozilla until next week, though because I'm away from my place)

Do you have any Solaris 2.7 (Solaris 8/9 has no problem. comment #1) box you can
lay  your hands on? Roland and  Masaki, do you have any?  I have 'ssh' access to
one, but I can't run Mozilla there. 
 


Assignee: ccarlen → jshin

    
    

    
  
Test results from CVS PULL of June03 08:00 MST:

the build is _BAD_

according the CVS log file cvsco.log, the only updated files from this time
compared to June03 00:00 MST (which seemed okay, except perhaps mailtool a bit
flakey ) are:

U mozilla/directory/c-sdk/config/nfspwd
U mozilla/xpcom/build/dlldeps.cpp
U mozilla/xpcom/io/nsNativeCharsetUtils.cpp

p.s. I start mozilla with mail tool coming up only at startup (in case its
important to you )


    
    

    
  
A final observation for this morning:

I pulled the june16 build off of mozilla.org:

it is also _BAD_ (at least on my machines/OS )  :-(

    
    

    
  
Robert, does filepicker work fine with a recent build? That is, can you open a
file or save (a web page or like) to a file navigating through your file system
(directory tree) and making a new directory? That's another place where
functions in NativeCharsetUtils are used.  

Did you build your binary with debug turned on? If so, can you redirect both
stdout and stderr to a file and see if there's anything unusual (perhaps
grepping with 'nsNativeCharsetUtils.cpp' or 'nsLocalFileUnix.cpp' or 'profile'
would suffice)? 

    
    

    
  
RE SAVE WEB PAGE:
It does not seem to be working:
the directory to save to (in the dialog) seems to be missing LAST character !
in fact all the directories (in pull down menu) to save to are missing the last
character!

this is on my build of june20, afternoon!,

next time i do a build, i will turn on debug :-)

    
    

    
  
Thanks for the test. It's beyond me how one-char gets chopped off at the end 
with UCS-2 -> UTF-16 change considering that iconv tests all worked well.
Because of this, you can't save to a file, can you? Can you open a file (html or
txt, jpg, png, etc)? 

The patch list for Solaris 2.7 (Sun OS 5.7) at
http://irb.cs.tu-berlin.de/dienste/solaris/sunos/5.7/Synopsis/?05-Jun-03

has some iconv patches. None of them seem to be relevant (one of them is about
'1byte' being short, but ....). Nonetheless,  it may be a good idea to make sure
that iconv patches listed there are all applied with 'showrev -p' and apply them
if not. (see also
http://docs.sun.com/db/doc/806-1151/6jaf56tf8?a=view)

    
    

    
  
yes ; patches 107962 & 102689 look interesting, but they don't seem to public
patches, and they don't come with the recommended patch cluster & they are not
installed on our machines, as we have no access to them ( at least, that i can
figure out)

No, i cannot save a html->file with default dialog settings :-(

    
    

    
  
Adding Darin to CC (I thought he's on). 

Robert, is there any chance that there are two iconv(3)'s lurking around and all
your test programs use one iconv(3) while Mozilla refers(is linked) to the other
at run-time? Can you try 'ldd -v libxpcom.so' and 'ldd -v ico*' ? You don't set
LD_LIBRARY_PATH, don't you? 

    
    

    
  
well i did have ld_library_path set, but no sign of a DEF of iconv, only UNDEFs in
in the directories, in  addition, i tried your stripped downns Native....cpp
again, like this:

[spruce]{404}[rsomerv]: unsetenv LD_LIBRARY_PATH
[spruce]{405}[rsomerv]: g++ -DICOCONST ico6.cpp -o ico6
[spruce]{406}[rsomerv]: ./ico6
abcd123
native string = abcd123
native string =  61 62 63 64 31 32 33
native string length = 7
native string left = 0
unicode string length = 7
unicode string =  0061 0062 0063 0064 0031 0032 0033
unicode string left = 0
native string = abcd123
native string =  61 62 63 64 31 32 33
native string length = 7



??????

    
    

    
  
p.s. I will be out of office (and country ) for some software training ,
starting wednesday afternoon for rest of this week  ;^)

    
    

    
  
Mitch, could you help me with this mysterious problem on Sun OS 5.7? Juding from
comment #1, probably you don't have Sun OS 5.7 box, do you? How about patches
107962 & 102689 (for Sun OS 5.7) mentioned by Robert in comment #44? Can he get
them somewhere? 

BTW, Darin, I found that Seamonkey-ports tinderbox on Sun OS 5.7 had been
'yellow' as far back as tinderbox lets me go (I manually subtracted 86400 x 15
and put it in the url - get - to go back to early June when my patch to  bug
206811 was landed, but apparently the record is not kept that long.). It's been
failing in bloat test. Does it have to do with the symptom we're dealing with here? 

    
    

    
  
I have tried a local build on 5.7 with no problems mentioned in this
bug. However i have  gcc 2.95.3 build and with gnu iconv. No issues
at all. Reporter try to a 2.95.3 compiled build

    
    

    
  
would this option do anything nice ? i just added it to .mozconfig

ac_add_options --enable-native-uconv

if fact, here is complete config as it now stands: (with gcc-3.2.3)

# Build configuration script
#
# See http://www.mozilla.org/build/unix.html for build instructions.
#

# Options for client.mk.
mk_add_options MOZ_MAKE_FLAGS=-j3

###mk_add_options MOZ_CO_DATE="2003-06-03 08:00"


# Options for 'configure' (same as command-line options).
ac_add_options --with-pthreads
ac_add_options --enable-calendar
ac_add_options --enable-crypto
ac_add_options --disable-tests
ac_add_options --enable-js-ultrasparc
ac_add_options --disable-debug
ac_add_options --enable-optimize=" -Os -mcpu=v9 -mtune=v9 -pipe"
ac_add_options --enable-strip
ac_add_options --enable-native-uconv
#ac_add_options --enable-static

    
    

    
  
Robert, enabling native-iconv can only worsen the problem because with that,
iconv(3) is a lot more extensively used than without.  Mozilla has its own
charset converters and use them most of time and iconv(3) is only used in
nsILocalFile.

Mitch, thanks for testing. I suspect it's  Solaris iconv vs GNU libiconv (if
it's indeed iconv(3) that's to blame) rather than gcc 2.95 vs gcc 3.2(?) that
made a difference. Could you get rid of GNU libiconv in your run-time lib.
search path and see how your build works with Solaris 2.7's default iconv?

   

    
    

    
  
I have GNU iconv compiled statically since i don't want many external
dependencies since people use the internal builds at home, so i
can't test out by moving LD_LIBRARY_PATH.

I'll try recompiling without it statically compiled and report.


    
    

    
  
i recompiled with gcc 2.95.3, no improvement in condition!

by using the old 'nsNative... `.cpp , i have no problem

    
    

    
  
I have successfully linked the latest Mozilla against the GNU iconv library, and
the browser seems to work flawlessly ! Maybe somebody could add a note to build
instructions something to the effect that Solaris-7 iconv is flawed, and to use
GNU iconv instead ??

-thanks , Robert Somerville
Flags: blocking1.4?

    
    

    
  
Robert, thanks for your work. It seems that something very strange is going on
with iconv(3) in Solaris 2.7 (that is, UCS-2 and UTF-16 do make a difference
even for trivial cases of ASCII chars.)

The point of this bug is to make Solaris build work with the default iconv(3) in
Solaris 2.7 so that it'd be nice if you could continue to help. 

Can you try

http://sunsolve.sun.com/pub-cgi/findPatch.pl?patchId=107962&rev=01
and 
http://sunsolve.sun.com/pub-cgi/findPatch.pl?patchId=102689&rev=01

to get patches mentioned in comment #45 (after registering/signing in)? 

> build instructions something to the effect that Solaris-7 iconv 
> is flawed, and to use GNU iconv instead ??

  Doesn't _run-time_ switching (with LD_LIBRARY_PATH) to GNU libiconv work with
a recent nightly build (downloaded from mozilla.org)? 
 


    
    

    
  
RE Patches:
Unfortunatly , we seem to need a contract, which we do not have to get at those
2 patches :-(  , i will try LD_LIBRARY_PATH later, Should i set it outside
run-mozilla.sh script,  or inside for safety ???

    
    

    
  
Mitch, have you managed to test Mozilla (NOT statically linked to GNU libiconv)
on Solaris 2.7?

Robert, sorry for the delay. I guess appending to LD_LIBRARY_PATH  the directory
with GNU libiconv.so can be done either inside or outside run-mozilla.sh. 

    
    

    
  
  Mitch, have you managed to test Mozilla (NOT statically linked to GNU 
  libiconv) on Solaris 2.7?

Nope, since we don't have any 5.7 boxes to test it on either (in 5.8 and 5.9 it
works perfectly *without* GNU libiconv). Also i don't see how either of
the two patches mentioned (107962 & 102689) can have any affect on this bug
since one is for session registration and the other one only affects chinese and
taiwanese locale.

It's more likely that path 112689-02 fixed the problem. 

I think we should close this bug and add in the README for mozilla on Solaris 7
that this patch is mandatory, or mozilla must be built with GNU iconv (for
customers don't have support contract for the patches).

    
    

    
  
robert somerville wrote:
> RE Patches:
> Unfortunatly , we seem to need a contract, which we do not have to get at 
> those 2 patches :-(  , i will try LD_LIBRARY_PATH later, Should i set it 
> outside run-mozilla.sh script,  or inside for safety ??

Hint: Many sites mirror the Sun patches (usually without caring about "private"
vs. "public" patches) - Google can give you possible download locations... =:-)

WARNING (just to ensure that noone can complain if problems occur):
When downloading patches from non-Sun sites please check the checksum of the
downloaded *.zip archives against the checksums at the Sun page to avoid that
you install a broken or "infected" patch.
Patch checksums are available from ftp://sunsolve.sun.de/pub/patches/CHECKSUMS
The checksum entry for 112689-02.zip is
-- snip --
112689-02.zip
      MD5: 25401dab11c340ff2c5d1076a81cc631
      SysV Sum: 58492   6028
      Sum: 60290   6028
-- snip --
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
I just did some tests with appying 112689-02 to my Solaris 2.7/SPARC machine and
backing it out.
Without the patch all hell breaks loose - the content of the mozilla folder is
split over "~/.mozill" and "~/.mozilla", files cannot be read at startup anymore
and plugins are not recognised. Fun... ;-(
Applying 112689-02 fixes the problem.

Jungshik Shin:
If you agree we can close this bug and I'll update the release notes, OK ?
Keywords: relnote
Whiteboard: Bug in Solaris, please apply Solaris patch 112689-02 (or higher) to cure it

    
    

    
  
Roland. thanks for testing on Solaris 2.7 with and without 'the' patch. I'm glad
that the cause was finally nailed down (and it's not mozilla).  Pls, close this
bug (I'm not sure which to choose, 'invalid' or 'works for me' or just 'fixed')
and update rel. notes accordingly.  

    
    

    
  
Release notes updated...

Checking in full-release-notes.shtml;
/cvsroot/mozilla-org/html/releases/full-release-notes.shtml,v  <-- 
full-release-notes.shtml
new revision: 1.234; previous revision: 1.233
done
Checking in mozilla1.3/index.html;
/cvsroot/mozilla-org/html/releases/mozilla1.3/index.html,v  <--  index.html
new revision: 1.37; previous revision: 1.36
done
Checking in mozilla1.3.1/index.html;
/cvsroot/mozilla-org/html/releases/mozilla1.3.1/index.html,v  <--  index.html
new revision: 1.23; previous revision: 1.22
done
Checking in mozilla1.3b/index.html;
/cvsroot/mozilla-org/html/releases/mozilla1.3b/index.html,v  <--  index.html
new revision: 1.30; previous revision: 1.29
done
Checking in mozilla1.4/installation-ports.html;
/cvsroot/mozilla-org/html/releases/mozilla1.4/installation-ports.html,v  <-- 
installation-ports.html
new revision: 1.4; previous revision: 1.3
done
Checking in mozilla1.4a/index.html;
/cvsroot/mozilla-org/html/releases/mozilla1.4a/index.html,v  <--  index.html
new revision: 1.25; previous revision: 1.24
done
Checking in mozilla1.4b/index.html;
/cvsroot/mozilla-org/html/releases/mozilla1.4b/index.html,v  <--  index.html
new revision: 1.31; previous revision: 1.30
done
Checking in mozilla1.4rc1/index.html;
/cvsroot/mozilla-org/html/releases/mozilla1.4rc1/index.html,v  <--  index.html
new revision: 1.24; previous revision: 1.23
done
Checking in mozilla1.4rc2/index.html;
/cvsroot/mozilla-org/html/releases/mozilla1.4rc2/index.html,v  <--  index.html
new revision: 1.21; previous revision: 1.20
done
Checking in mozilla1.4rc3/index.html;
/cvsroot/mozilla-org/html/releases/mozilla1.4rc3/index.html,v  <--  index.html
new revision: 1.20; previous revision: 1.19
done
Checking in mozilla1.5a/installation-ports.html;
/cvsroot/mozilla-org/html/releases/mozilla1.5a/installation-ports.html,v  <-- 
installation-ports.html
new revision: 1.4; previous revision: 1.3
done

... marking bug as FIXED.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED

    
    

    
  
*** Bug 213298 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 216928 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 228419 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: