debug help request
jerry.needell at unh.edu
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
Destructor invoked 4 times
Task_2: Setting the key to 2
Task_2: Got the key value of 2
Init: pthread_key_delete - SUCCESSFUL
Destructor invoked 5 times
*** END OF POSIX TEST 6 ***
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:
>>#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.com
>rtems-users mailing list
>rtems-users at rtems.com
More information about the users