[Gc] gc7alpha 9 asserts on Solaris x86

Boehm, Hans hans.boehm at hp.com
Tue May 15 15:11:03 PDT 2007


Thanks for the bug report.

Here's the line of reasoning by which this should be impossible.
Hopefully that may help in tracking this down a bit further:

1) The GC_INIT() macro is being called.
2) On Solaris GC_INIT() just calls GC_init()
3) GC_init() always calls GC_init_inner, which always sets
GC_is_initialized
4) GC_is_initialized is never reset
5) After GC_init() returns, GC_malloc() is called
6) GC_malloc's assertion that GC_is_initialized is set, fails
7) But this can't happen, since GC_is_initialized was clearly set

It should be fairly easy to figure out which of these steps is wrong.
It looks like this is failing purely for reasons of initialization
logic; it doesn't sound to me like anything complicated is going on yet.

I wouldn't expect REDIRECT_MALLOC to work with threads.  The usual
problem is that that during startup the loader allocates memory through
other undocumented means, and then stores pointers to malloc'ed memory
into this GC-invisible region.  On Linux,this may now work, but it
required some ugly platform-dependent hacks, which aren't there for
Solaris.

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