debug help request

Jerry Needell jerry.needell at
Wed Nov 15 13:51:39 UTC 2006

Joel -  Just some more information -I loaded psx06.exe into a 
GR-XC3S-1500 development board with a LEON3 processor and it ran as 
below - I'm not sure what it SHOULD look like, but no crash!

*** POSIX TEST 6 ***
Init's ID is 0x0b010001

Init: pthread_key_create - SUCCESSFUL
Destructor invoked 0 times
Init: pthread_key_create - EAGAIN (too many keys)
Init: pthread_setspecific - EINVAL (invalid key)
Init: pthread_getspecific - EINVAL (invalid key)
Init: pthread_key_delete - EINVAL (invalid key)
Init: Setting the key to 0
Init: Got the key value of 0
Task_1: Setting the key to 1
Task_1: Got the key value of 1
Task_1: exitting
Destructor invoked 4 times
Task_2: Setting the key to 2
Task_2: Got the key value of 2
Task2: exitting
Init: pthread_key_delete - SUCCESSFUL
Destructor invoked 5 times

Joel Sherrill wrote:

>FWIW I quadrupled the stack sizes in this test and it did not help.
>I also determined that the address being reported as being freed on
>the SPARC corresponds to an address that was allocated. 
>It looks like  it is being allocated from the workspace by libc_create_hook.
>That means that this could be a case of something writing beyond their
>allocated memory.  So this one needs to be fixed.
>I will have to let this sit overnight ... if someone has an insight, it
>would be greatly appreciated.
>Joel Sherrill wrote:
>>psx06 fails on sparc and mips during the pthread_exit.  It gets
>>an exception while doing a _Heap_Free.  I am totally disgusted
>>and confused at this point because on sparc, it appears that
>>every local variable of interest has been optimized away and
>>the backtrace is of little help.
>>On mipsjmr3904, the stack track is:
>>(gdb) bt
>>#0  0xffffffff8800b468 in _Heap_Free ()
>>#1  0xffffffff880027d4 in libc_delete_hook ()
>>#2  0xffffffff8800e3ec in _User_extensions_Thread_delete ()
>>#3  0xffffffff8800c860 in _Thread_Close ()
>>#4  0xffffffff880060e4 in pthread_exit ()
>>#5  0xffffffff8800084c in Task_2 ()
>>#6  0xffffffff88013fec in _Thread_Handler ()
>>#7  0xffffffff88013ee0 in _Thread_Evaluate_mode ()
>>#8  0xffffffff88013ee0 in _Thread_Evaluate_mode ()
>>On PowerPC/psim it appears to work OK.
>>Can someone give it a try on their target and see if they can
>>figure out what the bug is?
>>rtems-users mailing list
>>rtems-users at
>rtems-users mailing list
>rtems-users at

More information about the users mailing list