Subject: pkg/21569: boehm-gc update to 6.2a5
To: None <gnats-bugs@gnats.netbsd.org>
From: None <marc@informatik.uni-bremen.de>
List: netbsd-bugs
Date: 05/14/2003 00:42:34
>Number:         21569
>Category:       pkg
>Synopsis:       boehm-gc update to 6.2a5
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    pkg-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Tue May 13 22:43:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Marc Recht
>Release:        NetBSD 1.6T
>Organization:
	
>Environment:
	
	
System: NetBSD leeloo.intern.geht.de 1.6T NetBSD 1.6T (LEELOO) #0: Tue May 13 21:20:37 CEST 2003 root@leeloo.intern.geht.de:/sys/arch/i386/compile/LEELOO i386
Architecture: i386
Machine: i386
>Description:
Update to 6.2a5

Changes since 6.2alpha4:
 - GC_invoke_finalizers could, under rare conditions, set
   GC_finalizer_mem_freed to an essentially random value.  This could
   possibly cause unbounded heap growth for long-running applications
   under some conditions.  (The bug was introduced in 6.1alpha5, and
   is not in gcc3.3.  Thanks to Ben Hutchings for finding it.)
 - Attempted to sanitize the various DLL macros.  GC_USE_DLL disappeared.
   GC_DLL is used instead.  All internal tests are now on GC_DLL.
   README.macros is now more precise about the intended meaning.
 - Include DllMain in the multithreaded win32 version only if the
   collector is actually built as a dll.  (Thanks to Mohan Embar for
   a version of the patch.)
 - Hide the cygwin threadAttach/Detach functions.  They were violating our
   namespace rules.
 - Fixed an assertion in GC_check_heap_proc.  Added GC_STATIC_ASSERT.
   (Thanks again to Ben Hutchings.)
 - Removed some obsolete definitions for Linux/PowerPC in gcconfig.h.
 - CORD_cat was not rebalancing unbalanced trees in some cases, violating
   a CORD invariant.  Also tweaked the rebalancing rule for
   CORD_cat_char_star.  (Thanks to Alexandr Petrosian for the bug report
   and patch.)
 - Added hand-coded structured exception handling support to mark.c.
   This should enable support of dynamic libraries under win32 with
   gcc-compiled code.  (Thanks to Ranjit Mathew for the patch.)
   Turned on dynamic library scanning for win32/gcc.
 - Removed some remnants of read wrapping.  (Thanks to Kenneth Schalk.)
   GC_USE_LD_WRAP ws probably broken in recent versions.
 - The build could fail on some platforms since gcconfig.h could include
   declarations mentioning ptr_t, which was not defined, e.g. when if_mach
   was built.  (Thanks to Yann Dirson for pointing this out.)  Also
   cleaned up tests for GC_PRIVATE_H in gcconfig.h a bit.
 - The GC_LOOP_ON_ABORT environment variable interfered with incremental
   collection, since the write fault handler was erroneously overridden.
   Handlers are now set up in the correct order.
 - It used to be possible to call GC_mark_thread_local_free_lists() while
   the world was not stopped during an incremental GC.  This was not safe.
   Fortunately, it was also unnecessary.  Added GC_world_stopped flag
   to avoid it.  (This caused occasional crashes in GC_set_fl_marks
   with thread local allocation and incremental GC.  This probably happened
   primarily on old, slow multiprocessors.)
 - Allowed overriding of MAX_THREADS in win32_threads.c from the build
   command line.  (Patch from Yannis Bres.)
 - Taught the IA64/linux code to determine the register backing store base from
   /proc/self/maps after checking the __libc symbol, but before guessing.
   (__libc symbols are on the endangered list, and the guess is likely to not
   always be right for 2.6 kernels.)  Restructured the code to read and parse
   /proc/self/maps so it only exists in one place (all platforms).
 - The -DUSE_PROC_FOR_LIBRARIES code was broken on Linux.  It claimed that it
   also registered the main data segment, but didn't actually do so.  (I don't
   think anyone actually uses this configuration, but ...)
 - Made another attempt to get --enablecplusplus to do the right thing.
   Since there are unavoidable problems with C programs linking against a
   dynamic library that includes C++ code, I separated out the c++ code into
   libgccpp.
	
>How-To-Repeat:
	
>Fix:
http://www.geht.de/netbsd/pkgsrc/boehm-gc.diff.bz2
	
>Release-Note:
>Audit-Trail:
>Unformatted: