[Gc] gc7alpha 9 asserts on Solaris x86

jim marshall jim.marshall at wbemsolutions.com
Tue May 15 16:01:18 PDT 2007


Yes that was the cause. I thought I modified my include path to the GC7 
one, but I hadn't.  Doing that seems to have fixed the problem.

Thanks!
Jim

Boehm, Hans wrote:
> 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