pkgsrc-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/39012 (boehm-gc coredumps on GC_INIT under hpcmips (mipsel))
As I suspected, a quick work around is to simply disable
DYNAMIC_LOADING in the Boehm garbage collector. I have recompiled
gc-7.0 and verified that libgc works as expected (or, at least, it
doesn't dump core like the one currently available in pkgsrc).
I have a patch (below) which skips the #define of DYNAMIC_LOADING when
NETBSD and MIPSEL are defined. While this is not the optimal solution,
it is more correct then what is currently shipping. By the way, this
patch to boehm-gc will make the w3m package, and perhaps others,
compile cleanly instead of breaking.
--Ben
--- include/private/gcconfig.h.orig 2007-06-28 17:00:09.000000000 -0700
+++ include/private/gcconfig.h 2008-07-20 05:25:28.000000000 -0700
@@ -1397,7 +1397,13 @@
extern int etext[];
# define DATASTART GC_data_start
# define NEED_FIND_LIMIT
-# define DYNAMIC_LOADING
+/* Sadly, DYNAMIC_LOADING is broken for NetBSD/mipsel as of July 2008 */
+# ifdef __MIPSEL__
+# warning "DYNAMIC_LOADING support is broken for little endian MIPS"
+# undef DYNAMIC_LOADING
+# else
+# define DYNAMIC_LOADING
+# endif /* __MIPSEL__ */
# else
# define DATASTART ((ptr_t) 0x10000000)
# define STACKBOTTOM ((ptr_t) 0x7ffff000)
On 7/7/08, ben%wongs.net@localhost <ben%wongs.net@localhost> wrote:
> Additional information:
>
> I have tried building boehm-gc from the latest pkgsrc and can now
> provide a more precise backtrace.
>
> Script started on Mon Jul 7 05:30:12 2008
> bash-3.2# gdb ./a.out
> GNU gdb 5.3nb1
> Copyright 2002 Free Software Foundation, Inc.
> This GDB was configured as "mipsel--netbsd"...
> (gdb) run
> Starting program: /usr/pkgsrc/devel/boehm-gc/work/gc-7.0/a.out
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x7df456e8 in GC_find_limit_with_bound () at os_dep.c:917
> 917 GC_noop1((word)(*result));
> (gdb) c
> Continuing.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x7df456e8 in GC_find_limit_with_bound () at os_dep.c:917
> 917 GC_noop1((word)(*result));
> (gdb) c
> Continuing.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x7df3b920 in GC_FirstDLOpenedLinkMap () at dyn_load.c:455
> 455 = ((struct r_debug *)(dp->d_un.d_ptr))->r_map;
>
> (gdb) list
> 450 if( cachedResult == 0 ) {
> 451 int tag;
> 452 for( dp = _DYNAMIC; (tag = dp->d_tag) != 0; dp++ ) {
> 453 if( tag == DT_DEBUG ) {
> 454 struct link_map *lm
> 455 = ((struct r_debug *)(dp->d_un.d_ptr))->r_map;
> 456 if( lm != 0 ) cachedResult = lm->l_next; /*
> might be NIL */
> 457 break;
> 458 }
> 459 }
>
> (gdb) bt
> #0 0x7df3b920 in GC_FirstDLOpenedLinkMap () at dyn_load.c:455
> #1 0x7df3b9f0 in GC_register_dynamic_libraries () at dyn_load.c:475
> #2 0x7df42cd0 in GC_push_roots () from ./.libs/libgc.so.1
> #3 0x7df422d4 in GC_mark_some () from ./.libs/libgc.so.1
> #4 0x7df3809c in GC_stopped_mark () from ./.libs/libgc.so.1
> #5 0x7df384d8 in GC_try_to_collect_inner () from ./.libs/libgc.so.1
> #6 0x00400adc in main (argc=1, argv=0x7fffdca4, envp=0x7fffdcac) at
> gctest.c:7
> (gdb) quit
> The program is running. Exit anyway? (y or n) y
> bash-3.2# exit
>
> Script done on Mon Jul 7 05:31:04 2008
>
> Note that the first two segfaults are red herrings. Apparently some
> OSes (including NetBSD?) do not have a native way to find the
> beginning and end of the main data segment, so boehm-gc must perform a
> search at startup which causes segmentation faults.
>
> The true bug appears to be releated to the dynamic library tracing
> routines in dyn_load.c. The following page has helpful information
> about the porting changes necessary to enable dynamic library support:
>
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/porting.html
>
> The page also mentions that if DYNAMIC_LOADING is undefined in
> gcconfig.h, tracing of dynamic library data will be disabled. This
> might be a quick, if rather unsatisfying, way to get boehm-gc
> "working" in NetBSD/mipsel.
>
> --Ben
>
Home |
Main Index |
Thread Index |
Old Index