Closed Bug 81735 Opened 23 years ago Closed 23 years ago

Build for leaks tests won't run.

Categories

(Core Graveyard :: Embedding: GTK Widget, defect, P1)

Product:
Core Graveyard
Component:
Embedding: GTK Widget
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: curt, Assigned: cls)

Details

(Whiteboard: fix in hand, waiting for review.) 

I get a segmentation fault.
The build I'm using can be found at /u/curt/boehm/cm/mozilla.
The build output, including the configuration, is in 
/u/curt/boehm/cm/mozilla/out.

Below is a cut and paste of the error message and trace, although it is more 
readable if you look at /u/curt/boehm_breakage.txt

-----------------------------------------------




[[registering roots 4020a000-4020b000 for mmap: mmap zero]]
[[registering 
roots 4020b000-4020d000 for mmap: /lib/libdl-2.1.92.so]]
[[registering roots 
4020d000-4020e000 for mmap: /lib/libdl-2.1.92.so]]
[[registering roots 
4020e000-40213000 for mmap: 
/u/curt/boehm/cm/mozilla/widget/src/gtksuperwin/libgtksuperwin.so]]
[[registering roots 40213000-40214000 for mmap: 
/u/curt/boehm/cm/mozilla/widget/src/gtksuperwin/libgtksuperwin.so]]
[[registering roots 40214000-4033e000 for mmap: /usr/lib/libgtk-1.2.so.0.5.3]]
[[registering roots 4033e000-40345000 for mmap: /usr/lib/libgtk-1.2.so.0.5.3]]
[[registering roots 40345000-40346000 for mmap: mmap zero]]
[[registering roots 
40346000-4037a000 for mmap: /usr/lib/libgdk-1.2.so.0.5.3]]
[[registering roots 
4037a000-4037c000 for mmap: /usr/lib/libgdk-1.2.so.0.5.3]]
[[registering roots 
4037c000-4037e000 for mmap: /usr/lib/libgmodule-1.2.so.0.0.8]]
[[registering 
roots 4037e000-4037f000 for mmap: /usr/lib/libgmodule-1.2.so.0.0.8]]
[[registering roots 4037f000-403a2000 for mmap: 
/usr/lib/libglib-1.2.so.0.0.8]]
[[registering roots 403a2000-403a4000 for mmap: 
/usr/lib/libglib-1.2.so.0.0.8]]
[[registering roots 403a4000-403ab000 for mmap: 
/usr/X11R6/lib/libXi.so.6.0]]
[[registering roots 403ab000-403ac000 for mmap: 
/usr/X11R6/lib/libXi.so.6.0]]
[[registering roots 403ac000-403b9000 for mmap: 
/usr/X11R6/lib/libXext.so.6.4]]
[[registering roots 403b9000-403ba000 for mmap: 
/usr/X11R6/lib/libXext.so.6.4]]
[[registering roots 403ba000-403bb000 for mmap: 
mmap zero]]
[[registering roots 403bb000-40484000 for mmap: 
/usr/X11R6/lib/libX11.so.6.1]]
[[registering roots 40484000-40488000 for mmap: 
/usr/X11R6/lib/libX11.so.6.1]]
[[registering roots 40488000-40489000 for mmap: 
mmap zero]]
[[registering roots 40489000-404a8000 for mmap: 
/lib/libm-2.1.92.so]]
[[registering roots 404a8000-404a9000 for mmap: 
/lib/libm-2.1.92.so]]
[[registering roots 404a9000-405c4000 for mmap: 
/lib/libc-2.1.92.so]]
[[registering roots 405c4000-405ca000 for mmap: 
/lib/libc-2.1.92.so]]
[[registering roots 405ca000-405ce000 for mmap: mmap 
zero]]
[[registering roots 405ce000-40607000 for mmap: 
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so]]
[[registering roots 40607000-4060e000 
for mmap: /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so]]
[[registering roots 
4060e000-40612000 for mmap: mmap zero]]
[[registering roots bfffe000-c0000000 
for mmap: mmap zero]]
[[register mmap data finish.]]

Program received signal 
SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 10306)]
0x40166267 
in GC_mark_from_mark_stack () at mark.c:502
502           current = 
*current_p;
Current language:  auto; currently c              
(gdb) bt
#0  
0x40166267 in GC_mark_from_mark_stack () at mark.c:502
#1  0x40165be3 in 
GC_mark_some (cold_gc_frame=0xbffff8a8 
"G¢\026@°á\006\b$\e\027@Ôøÿ¿1\001\026@\fü\025@$\e\027@Ôøÿ¿\016\001\026@")
    at 
mark.c:295
#2  0x40160410 in GC_stopped_mark (stop_func=0x4015fc0c 
<GC_never_stop_func>) at alloc.c:427
#3  0x40160131 in GC_try_to_collect_inner 
(stop_func=0x4015fc0c <GC_never_stop_func>) at alloc.c:306
#4  0x401688bd in 
GC_init_inner () at misc.c:544
#5  0x4016455a in GC_generic_malloc_inner (lb=92, 
k=1) at malloc.c:63
#6  0x40164714 in GC_generic_malloc (lb=92, k=1) at 
malloc.c:123
#7  0x40164924 in GC_malloc (lb=92) at malloc.c:197
#8  0x40161ef6 
in GC_debug_malloc (lb=64, s=0x40170821 "gc_cpp.cc", i=31) at dbg_mlc.c:360
#9  
0x4016e93b in __builtin_new (size=64) at gc_cpp.cc:31
#10 0x400da51b in 
EnsureLoggingService () at nsLogging.cpp:243
#11 0x400da80d in NS_GetLog 
(name=0x40148e6d "LogInfo", controlFlags=2) at nsLogging.cpp:308
#12 0x400dbcab 
in __static_initialization_and_destruction_0 (__initialize_p=1, 
__priority=65535)
    at ../../dist/include/nsBufferHandle.h:43
#13 0x400dbcd5 
in global constructors keyed to nsLoggingService::nsLoggingService () at 
../../dist/include/nsBufferHandle.h:353
#14 0x40111f45 in __do_global_ctors_aux 
() at nsString2.cpp:1928
#15 0x4008145e in _init () from 
/u/curt/boehm/cm/mozilla/dist/bin/./libxpcom.so
#16 0x4000de17 in _dl_init 
(main_map=0x40016c50, argc=1, argv=0xbffffad4, env=0xbffffadc) at 
dl-init.c:111
(gdb)
Why is this assigned to me?  And I can't look at that.  I'm not a netscape employee.
ok, the config settings for a boehm leak testing build is:

u/curt/boehm/scripts/build % cat .mozconfig
ac_add_options --enable-debug
ac_add_options --disable-tests
ac_add_options --enable-cpp-rtti
ac_add_options --enable-boehm

and the script used to create one of these nasty boys 
looks like:

!/bin/csh

#setenv CVSROOT :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot
setenv CVSROOT :pserver:curt%scruznet.com@cvs.mozilla.org:/cvsroot
setenv SCRIPTSDIR /u/curt/boehm/scripts/build
setenv BUILDDIR /u/curt/boehm/cm/mozilla
setenv OUTFILE $BUILDDIR/out
setenv CONFIGFILE $BUILDDIR/.mozconfig
rm -f $OUTFILE
cd $BUILDDIR/.. 
pwd > $OUTFILE
cvs co mozilla/client.mk >>& $OUTFILE
cd $BUILDDIR >>& $OUTFILE
pwd >> $OUTFILE
echo "*** CLOBBERING `date`\n" >> $OUTFILE
make -fclient.mk clobber >>& $OUTFILE
echo "*** PULLING `date`\n" >> $OUTFILE
make -fclient.mk checkout  >>& $OUTFILE
echo "*** CONFIGURING `date`\n" >> $OUTFILE
rm -f $CONFIGFILE
cp $SCRIPTSDIR/.mozconfig $CONFIGFILE
cat $CONFIGFILE >> $OUTFILE
./configure              >>& $OUTFILE
echo "*** BUILDING `date`\n" >> $OUTFILE
make -fclient.mk build   >>& $OUTFILE
echo `date` >> $OUTFILE
echo Done. >> $OUTFILE
ls -l $OUTFILE


looking for helpers to sort the build problems out
so we can start posting leak results again...
Could something have changed when _PR_InitStuff is called?  Or something else
like that?

(I don't think I've ever gotten the boehm GC to work with GtkEmbed,though.)
I just did a boehm GC build of mozilla for the first time in a while and it
doesn't run either.  Do we know what the time frame is for when this broke?
I had issues just getting libboehm.so to link because of the use of -Bsymbolic
when creating the shared lib so I'm suspecting that change (bug 76710) may have
broken it.  Trying a build with that patch reverted.

The last good test I got was on the 9th.  There were some other testing problems 
going on, though, so the checkin that broke this may have come a bit later, like 
around the 11th or the 14th.  Chris, it looks like the checkin you are refering 
to happened on the 17th (?) which seems a bit late, but I'm not ruling it out.
Yeah, rebuilding just libboehm.so without -Wl,-Bsymbolic fixes it.
Taking the bug
Assignee: blizzard → cls
Priority: -- → P1
Target Milestone: --- → mozilla0.9.1
Need rubberstamp for pdt.

Index: configure.in
===================================================================
RCS file: /cvsroot/mozilla/configure.in,v
retrieving revision 1.863
diff -u -r1.863 configure.in
--- configure.in	2001/05/22 07:52:23	1.863
+++ configure.in	2001/05/23 16:44:18
@@ -729,7 +729,6 @@
     AC_DEFINE(_POSIX_SOURCE)
     AC_DEFINE(_SVID_SOURCE)
     TARGET_NSPR_MDCPUCFG='\"md/_linux.cfg\"'
-    DSO_LDOPTS="$DSO_LDOPTS -Wl,-Bsymbolic"
     LIBS="$LIBS -lc"
 
     case "${host_cpu}" in
Whiteboard: fix in hand, waiting for review.
a=blizzard for 0.9.1
Patch has been checked in.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Works now.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.