Stack_check_Dump_threads_usage printing out the wrong values

[groups at chichak.ca]

> On 2017-November-15, at 16:10, Chris Johns <chrisj at rtems.org> wrote:
> 
> On 16/11/2017 09:50, Mr. Andrei Chichak wrote:
>> I’m working with 4.12 for ARM   (cortex M7)
>> 
>> I’m tracing down an issue and figured it smelled like a stack problem, so I got
>> my command line interpreter to call rtems_stack_checker_report_usage().
>> 
>> The addresses that it is printing out are just wrong.
>> 
>>                             STACK USAGE BY THREAD
>> ID         NAME                  LOW        HIGH       CURRENT    AVAIL  USED
>> 0x09010001 IDLE                  0x536902024 0x536906119 0x536906024   4080    164
>> 0x0A010001 UI1                   0x536906128 0x536910223 0x536910112   4080    404
>> 0x0A010002 CfgT                  0x536910232 0x536914327 0x536914120   4080    288
>> 0x0A010003 LOGT                  0x536914728 0x536918823 0x536918248   4080    648
>> 0x0A010004 MonT                  0x536918832 0x536922927 0x536922592   4080    404
>> 0x0A010005 ADCT                  0x536922936 0x536927031 0x536926712   4080    388
>> 0x0A010006 CSLT                  0x536927040 0x536931135 0x536930512   4080   1236
>> 
>> So I started chasing the source code and I find that on line 408 of check.c in
>> function Stack_check_Dump_threads_usage, in the line:
>> 
>>  rtems_printf(
>>    printer,
>>    "0x%08" PRIx32 " %-21s 0x%08" PRIuPTR " 0x%08" PRIuPTR " 0x%08" PRIuPTR "
>> %6" PRId32 " ",
>>    id,
>>    name,
>>    (uintptr_t) stack->area,
>>    (uintptr_t) stack->area + (uintptr_t) stack->size - 1,
>>    (uintptr_t) current,
>>    size
>>  );
>> 
>> Stack->area has the value 0x20009998 and the value of stack->size is 4096  ( for
>> process CfgT). Current has the value 0x2000a8c8.
>> 
>> AH, I get it, the values are being prepended with 0x and then printing out in
>> decimal instead of hex.
> 
> Nice fine.
> 
>> 
>> Perhaps in the format, the PRIuPTRs should be PRIx32s instead???
>> 
> 
> Or PRIxPTR?

Yes, I think that PRIxPTR would be the correct pick.

(I don’t know how to proceed with getting this reported/fixed.)

> 
> Chris

Andrei