Re: #215067 mozilla FTBFS
On Wed, 2003-10-15 at 09:42, Adam C Powell IV wrote:
> On Tue, 2003-10-14 at 08:51, Mark Howard wrote:
> > Hi,
> > This seems to be the final issue holding back mozilla, galeon and
> > epiphany from testing. It would be really great if we could get these
> > into testing as soon as possible since they are all major updates.
> >
> > Could people on this list please take a look at the build problem. If
> > it's something very non-trivial, please say so.
>
> Just so others on Debian-ARM know, I'm working on it, but NFS is being
> flaky, it died (couldn't access the mounted dir, couldn't kill processes
> using it, couldn't unmount, had to reboot) about 2/3 of the way through
> the first build attempt and is making its way through the second...
>
> Can't promise anything, but I should be able to produce a backtrace.
I'm sorry about the delay, didn't have a solid block of time to sink
into this until now.
First, gdb just doesn't work, there's no backtrace even though I haven't
stripped anything. I do "run -v -i [the shlib file where it fails]",
and get only:
[New Thread 16384 (LWP 9235)]
Cannot access memory at address 0x0
(gdb) backtrace
#0 0x00000000 in ?? ()
(gdb)
Second, Mozilla's build system is an opaque bunch of nested .mk files
scattered around. After about an hour of wading through stuff, I
kludged together a way to rebuild shlibsign with a bunch of printfs, and
all that told me is that NSS_Init returns -1, which is not SECSuccess
(which would be 0), then the segfault happens during NSS_NoDB_Init("").
After another hour, I realized that it was ignoring all my printfs in
nssinit.c because at runtime it was linking with libnss3.so from an
installed mozilla 1.3! (D'oh!) So I set LD_LIBRARY_PATH and learned
the following:
During the call to NSS_Init, nss_makeFlags(1,0,0,0,0,1) returns 0x219a8,
and the resulting moduleSpec is:
name="NSS Internal Module" parameters="configdir='/home/hazelsct/.netscape' certPrefix='' keyPrefix='' secmod='secmod.db' flags=readOnly,optimizeSpace " NSS="flags=internal,moduleDB,moduleDBOnly,critical"
Then SECMOD_LoadModule() returns something non-null, but apparently
->loaded is zero because nss_Init returns -1.
During the call to NSS_NoDB_Init, nss_makeFlags(1,1,1,1,0,1) returns
0x25268 (okay, maybe this is an address whose value is meaningless, not
what I thought), and the resulting moduleSpec is:
name="NSS Internal Module" parameters="configdir='' certPrefix='' keyPrefix='' secmod='' flags=readOnly,noCertDB,noModDB,forceOpen,optimizeSpace " NSS="flags=internal,moduleDB,moduleDBOnly,critical"
Then ->loaded seems to work, because it calls secoid_Init(), then
segfaults in the call to STAN_LoadDefaultNSS3TrustDomain(). Which in
turn segfaults in NSSTrustDomain_Create(), which segfaults in
NSSArena_Create(). (God, how I wish I could just "backtrace"!!)
Then I'm stuck, because when I modify security/nss/lib/base/arena.c and
recompile, there are missing symbols (nssPointerTracker_add, _verify,
_initialize and _remove) when linking shlibsign, and I can't see how to
fix it without sending this thing on another day-long build campaign.
So that's where I've narrowed the problem to. I can't really put any
more time into it tonight, and can't promise I'll be able to soon, but
will do my best to follow up on subsequent suggestions. Heck, now that
I've put this much into it, I'm motivated to make it actually work! :-)
I hope this bit of effort helps someone to figure out what could be
causing this problem.
Thanks,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Reply to: