[Gc] gc7alpha 9 asserts on Solaris x86

Boehm, Hans hans.boehm at hp.com
Tue May 15 15:23:50 PDT 2007


It also occurs to me that there may that the definition of the GC_INIT()
macro hasn't been completely stable on some platforms.  It may be
necessary to recompile the GC_INIT caller with the current GC header
file.  Sorry about that.  Hopefully this will not need to change much in
the future.

Hans 

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of jim marshall
> Sent: Tuesday, May 15, 2007 2:46 PM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] gc7alpha 9 asserts on Solaris x86
> 
> We have an application that uses the GC 6.8, it works fine on 
> all platforms except x86 Solaris. It has been mentioned that 
> GC7 should fix the problem. I wanted to test GC7 alpha 9 and 
> see if it does fix the problem. Unfortunately it doesn't.  
> With GC6.8 the 'make check' would fail, now that passes but 
> my program gets an assertion from the GC:
> 
> Assertion failure: thread_local_alloc.c:153
> 
> assertion failure
> 
> Abort (core dumped)
> 
> 
> here is the configure I ran, perhaps I am using a wrong value?
> ./configure --enable-threads=posix 
> --enable-thread-local-alloc --enable-parallel-mark 
> --prefix=/files/jim/debug --exec-prefix=/files/jim/debug 
> --enable-gc-assertions --enable-full-debug
> 
> we can not use REDIRECT_MALLOC as it caused issues with libs 
> that where dlopen'd or something ( don't recall exactly why).
> 
> 
> here is the uname -a output
> 
> SunOS unknown 5.9 on81-fp-stage:10/31/2002 i86pc i386 i86pc
> 
> 
> Here is the stack trace.
> 
> 
> #0  0xddaef327 in _lwp_kill () from /usr/lib/libc.so.1
> #1  0xdd69a4dd in thr_kill () from /usr/lib/libthread.so.1
> #2  0xddb50a0e in thr_kill () from /usr/lib/libc.so.1
> #3  0xddb054ad in raise () from /usr/lib/libc.so.1
> #4  0xddaf02ce in abort () from /usr/lib/libc.so.1
> #5  0xdda847f2 in GC_abort (msg=0xdda8e450 "assertion failure") at 
> misc.c:1067
> #6  0xdda89847 in GC_malloc (bytes=176) at thread_local_alloc.c:153
> #7  0xdda1c3ec in wsi_malloc (pSize=176) at wsimemory.c:31
> #8  0xdda1c493 in wsiMemAllocateDebug (nSize=152,
>     pszFileName=0xdda32f5c "./src/Linux/wsimoduleLinux.c", nLine=48)
>     at wsimemory.c:193
> #9  0xdda1c97c in wsiMemAllocate (nSize=152,
>     pszFileName=0xdda32f5c "./src/Linux/wsimoduleLinux.c", nLine=48)
>     at wsimemory.c:484
> #10 0xdda1cf5f in wsiHandleAllocate (nSize=4,
>     pszFileName=0xdda32f5c "./src/Linux/wsimoduleLinux.c", nLine=48)
>     at wsimemory.c:846
> #11 0xdda24ec5 in wsiModuleLoadA (pszModuleName=0xdd937008 "cimom", 
> nFlags=0,
>     phModule=0x8047794) at wsimoduleLinux.c:47
> #12 0xdd93482e in getCWBEMServerIniFile () at src/utils.c:396
> #13 0xdd934909 in get_Preferred_IPADDR () at src/utils.c:438
> #14 0xdd934a7f in get_system_ip () at src/utils.c:514
> #15 0x080510e5 in main (argc=2, argv=0x8047c58) at wsicimom.c:95
> 
> as an outline frame 15 calls GC_INIT(), it then calls into frame 14 
> which tries to dlopen a libray. But before it does the dlopen 
> is has to 
> build a platform specific name (e.g. libXXX.so), so it is allocating 
> memory for this string when we get the assert.
> 
> The program is multi-threaded, however; at the point of the assert we 
> only have the primary thread running.
> 
> thank you
> -jim
> 
> -- 
> Jim Marshall
> WBEM Solutions, Inc.
> 
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 



More information about the Gc mailing list