Status

NSPR
NSPR
--
blocker
RESOLVED WONTFIX
15 years ago
13 years ago

People

(Reporter: Joe Pepin, Assigned: Wan-Teh Chang)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Build Identifier: will not build

ranlib libnspr4.a
grep -v ';-' nspr.def | \
sed -e 's,;+,,' -e 's; DATA ;;' -e 's,;;,,' -e 's,;.*,;,' > nsprmap.sun
rm -f libnspr4.so
gcc -shared -Wl,-h,libnspr4.so,-z,combreloc,-z,defs -Wl,-f,\$ORIGIN/cpu/
\$ISALIST/libnspr_flt4.so -o libnspr4.so -Wl,-M,./nsprmap.sun ./prvrsion.o 
io/./prfdcach.o io/./prmwait.o io/./prmapopt.o io/./priometh.o io/./pripv6.o 
io/./prlayer.o io/./prlog.o io/./prmmap.o io/./prpolevt.o io/./prprf.o 
io/./prscanf.o io/./prstdio.o threads/./prcmon.o threads/./prrwlock.o 
threads/./prtpd.o linking/./prlink.o malloc/./prmem.o md/./prosdep.o 
memory/./prshm.o memory/./prshma.o memory/./prseg.o misc/./pralarm.o 
misc/./pratom.o misc/./prcountr.o misc/./prdtoa.o misc/./prenv.o misc/./prerr.o 
misc/./prerror.o misc/./prerrortable.o misc/./prinit.o misc/./prinrval.o 
misc/./pripc.o misc/./prlog2.o misc/./prlong.o misc/./prnetdb.o 
misc/./prolock.o misc/./prrng.o misc/./prsystem.o misc/./prthinfo.o 
misc/./prtpool.o misc/./prtrace.o misc/./prtime.o malloc/./prmalloc.o 
pthreads/./ptsynch.o pthreads/./ptio.o pthreads/./ptthread.o 
pthreads/./ptmisc.o memory/./prgcleak.o md/unix/./unix.o 
md/unix/./unix_errors.o md/unix/./uxproces.o md/unix/./uxrng.o 
md/unix/./uxshm.o md/unix/./uxwrap.o md/unix/./solaris.o md/unix/./os_SunOS.o -
L/home/mozilla/dist/lib -lboehm -lpthread -lthread -lrt -lsocket -lnsl -ldl -lc
Undefined                       first referenced
 symbol                             in file
GetStackTop                         pthreads/./ptthread.o
GC_print_call_tree                  /home/mozilla/dist/lib/libboehm.so
getTypeName                         /home/mozilla/dist/lib/libboehm.so
main                                /home/mozilla/dist/lib/libboehm.so
ld: fatal: Symbol referencing errors. No output written to libnspr4.so
collect2: ld returned 1 exit status
make[5]: *** [libnspr4.so] Error 1
make[5]: Leaving directory `/home/mozilla/nsprpub/pr/src'
make[4]: *** [export] Error 2
make[4]: Leaving directory `/home/mozilla/nsprpub/pr'
make[3]: *** [export] Error 2
make[3]: Leaving directory `/home/mozilla/nsprpub'
make[2]: *** [nspr] Error 2
make[2]: Leaving directory `/home/mozilla'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/home/mozilla'
make: *** [build] Error 2


Reproducible: Always

Steps to Reproduce:
1.cvs co mozilla/client.mk
2.cd mozilla
3.gmake -f client.mk

Actual Results:  
build failed

Expected Results:  
built happily like it used to ;)

It used to build just fine a month or so ago, I haven't changed anything to the 
best of my knowledge.
(Assignee)

Comment 1

15 years ago
Are you building on Sun Solaris?

Did you specify the --enable-boehm configure option?

I believe the --enable-boehm configure option is only
supported on Linux x86.

Comment 2

15 years ago
Reporter, is this still a problem ?

Comment 3

13 years ago
Yes, this is still a problem (found this bug while searching before filing the 
same report). Yes, --enable-boehm is passed - otherwise this doesn't manifest 
(I mean, honestly...). Munging the several Makefiles including this first 
occurance to do -lboehm on the LIBS line results in a binary but the binary 
fails to execute (see attached). As Mozilla and Firefox leak about half a gig 
of RAM/VM a day under heavy use, garbage collection would be really, really 
nice. In fact, Mozilla leaks faster than even RealServer which had to be the 
leakiest "production" code out there. 
 
Here's my ./configure: 
 
./configure  --prefix=/home/knoppix/ --enable-boehm --with-system-jpeg 
--with-system-png --with-system-zlib --with-x --disable-mailnews 
--disable-composer --disable-svg --enable-optimize=-O --disable-xul 
--with-libIDL-prefix=/home/knoppix --disable-ldap --enable-cpp-rtti 
--libdir=/home/knoppix/lib/ --includedir=/home/knoppix/include 
 
I'm building a stripped Mozilla rather than a Firefox as for some reason 
Mozilla leaks more slowly than Firefox does. I'm building on Knoppix (Debian 
Linux) to confirm the same problem as it exists on NetBSD. Hence this problem 
is not Linux specific. Now please don't ask any more "is the computer plugged 
in?" questions before accepting this report - the first reporter works at 
RedHat and is presumable both knowledgeable and busy, and you have 
confirmation. And the first reporter claimed this configuration used to work 
on his box so he's unlikely to be running a non-supported platform. For what 
it's worth, the Boehm garbage collection library's support for Linux is 
secondary to it's Solaris support and the API is identical so it would be 
truly odd if this configuration failed with Mozilla. 

Comment 4

13 years ago
Created attachment 170336 [details]
SEGV: invoked program's (built with --enable-boehm) debugging output

SEGV: invoked program's (built with --enable-boehm) debugging output

SEGV result of attempt to run a program built with --enable-boehm (after
Makefile's were munged to do -lboehm).
(Assignee)

Comment 5

13 years ago
The build output in the original description (comment 0)
clearly shows the build was done on Solaris SPARC and that
--enable-boehm was specified.  So you are right, my
questions in comment 1 were asking about the obvious.

The first undefined symbol, GetStackTop, is defined in
mozilla/nsprpub/pr/src/pthreads/ptthread.c as follows:

 97 #if defined(GC_LEAK_DETECTOR) && (__GLIBC__ >= 2) && defined(__i386__) 
...
118 static void* GetStackTop()
119 {
120     stack_frame* frame;
121     frame = GetStackFrame();
122     while (frame != NULL)
123     {
124         ptrdiff_t pc = (ptrdiff_t)frame->pc;
125         if ((pc < 0x08000000) || (pc > 0x7fffffff) || (frame->next < frame))
126             return frame;
127         frame = frame->next;
128     }
129     return NULL;
130 }
131 #endif /* GC_LEAK_DETECTOR && (__GLIBC__ >= 2) && __i386__ */

So it is only defined for Linux x86 (the only platform where
__GLIBC__ is >= 2 and __i386__ is defined).

The second undefined symbol, GC_print_call_tree, is defined in
mozilla/gc/boehm/misc.c as follows:

779 #if defined(MACOS) && defined(POWERPC)
...
819 #if NFRAMES > 2
...
841 #else
...
847 void GC_print_call_tree(call_tree* tree)
848 {
849     UInt32 file_offset;
850     if (GC_address_to_source((char*)tree->pc, symbol_name, file_name,
&file_offset)) {
851         MWUnmangle(symbol_name, unmangled_name, sizeof(unmangled_name));
852         GC_err_printf3("%s[%s,%ld]", unmangled_name, file_name, file_offset);
853     } else {
854         pc2name((word)tree->pc, symbol_name, sizeof(symbol_name));
855         MWUnmangle(symbol_name, unmangled_name, sizeof(unmangled_name));
856         GC_err_printf2("%s(%08X)", unmangled_name, tree->pc);
857     }
858 }
...
879 #endif /* NFRAMES > 2 */
880 
881 #elif defined(LINUX)
...
887 void GC_print_call_tree(call_tree* tree)
888 {
889     Dl_info dlinfo;
890     if (dladdr(tree->pc, &dlinfo) >= 0) {
891         unsigned offset = (tree->pc - dlinfo.dli_fbase);
892         GC_err_printf3("%s[%s +0x%08X]", dlinfo.dli_sname, dlinfo.dli_fname,
offset);
893     } else {
894         GC_err_printf2("%s(0x%08X)", "(unknown)", tree->pc);
895     }
896 }
...
919 #else
... 
950 #endif /* !MACOS */

So it's only defined on Mac OS (probably Mac OS Classic,
not Mac OS X) and Linux.

These two findings are sufficient for me to conclude that
Mozilla build with --enable-boehm specified is not supported
on Solaris SPARC.

I don't maintain the boehm code in Mozilla or NSPR, so
I'm going to mark this bug WONTFIX.

The problem reported in comment 3 is a different problem.
- It is a runtime crash on Knoppix (Debian Linux), not a
  build problem on Solaris SPARC.
- The debugging output provided in comment 4 does not contain
  either GetStackTop or GC_print_call_tree.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
OS: other → Solaris
Hardware: Other → Sun
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.