This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Unexpected address range accesses from bare metal code

Note: This was originally posted on 12th September 2012 at http://forums.arm.com

My test system (Carbon SoCD running a Cortex A9 model) has a memory map with entry point 0xFFFF0000, with a valid memory range from 0xFFFF0000-0xFFFFFFFF, as well as 0x50000000-0x8FFFFFFF where some stack, heap, data, etc. lives. My code is a simple dhrystone app and makes some printf calls to display the app's actions and status. However, I am strangely seeing access to low memory, reads going to 0xA or 0x38 for example. I've tried to debug where these are coming from but whatever is happening is hidden in some system library. Using the disassembly and my .map linker output I see that the code is in flsbuf.o or printf_char_common.o at the time. Depending on whether I comment out certain printf statements, the place/time the out of range access occurs is different. Does anyone have any clues as to what might be happening? Or more information that I can provide to help debug this?

If I comment out all the printfs, none of the out of range accesses occur. Also, if I adjust the system memory to be valid at those low memory addresses, the program executes and completes just fine. So I have a workaround of sorts but I want to make sure this won't be a problem for actual hardware.

Thanks,
Rich

Parents

Rich Podraza over 12 years ago

Note: This was originally posted on 19th September 2012 at http://forums.arm.com

Two thoughts, probably not useful:

1. flsbuf.o is probably only using the FILE obejct (allocated on the heap) so if it's making wild reads, perhaps the FILE object has been corrupted (by being overwritten?) Maybe try inserting some some heap checking by using '__heapvalid' (but perhaps not using fprintf).

2. If you tend to write 'printf(p)' instead of 'printf("%s", p)' then make sure that the string that 'p' points at doesn't have any (undoubled) '%'s in it.

Can you get a stack backtrace at the point of the wild access?

I tried upping my stack/heap size to 256 MB and still see the wild access. I will look up __heapvalid and try to see if that is helpful. In the meantime, I have tried some different things with the printf statements and am getting different behavior. This is taken from a dhrystone app.

printf("Running on CPU%d\n",getCpuNum()); /* Initializations */ Next_Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type)); Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type)); printf("Next_Ptr_Glob=0x%08X, Ptr_Glob=0x%08X\n", Next_Ptr_Glob, Ptr_Glob); // some code truncated here

The above code only gives me the output "Running on CPU 0" before the access. BUT,

printf("Running on CPU%d\n",getCpuNum()); /* Initializations */ Next_Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type)); Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type)); //printf("Next_Ptr_Glob=0x%08X, Ptr_Glob=0x%08X\n", Next_Ptr_Glob, Ptr_Glob); printf("Next_Ptr_Glob=%d, Ptr_Glob=%d\n", Next_Ptr_Glob, Ptr_Glob); Ptr_Glob->Ptr_Comp = Next_Ptr_Glob; Ptr_Glob->Discr = Ident_1; Ptr_Glob->variant.var_1.Enum_Comp = Ident_3; Ptr_Glob->variant.var_1.Int_Comp = 40; printf("RAP1\n"); strcpy (Ptr_Glob->variant.var_1.Str_Comp, "DHRYSTONE PROGRAM, SOME STRING"); strcpy (Str_1_Loc, "DHRYSTONE PROGRAM, 1'ST STRING"); printf("RAP2\n"); Arr_2_Glob [8][7] = 10; printf("RAP3\n"); /* Was missing in published program. Without this statement, */ /* Arr_2_Glob [8][7] would have an undefined value. */ /* Warning: With 16-Bit processors and Number_Of_Runs > 32000, */ /* overflow may occur for this array element. */ printf ("\n"); printf ("Dhrystone Benchmark, Version 2.1 (Language: C)\n"); printf ("\n"); if (Reg) { printf ("Program compiled with 'register' attribute\n"); printf ("\n"); } else { printf ("Program compiled without 'register' attribute\n"); printf ("\n"); } Number_Of_Runs = 999; printf ("Execution starts, %d runs through Dhrystone\n", Number_Of_Runs);

Gives the output
"
Running on CPU0
Next_Ptr_Glob=1879048228, Ptr_Glob=18799048344
RAP1
RAP2
RAP3

Dhrystone Benchmark, Version 2.1 (Language: C)

Program compiled without 'register' attribute
"
until the wild access. So it seems changing parameter types from %08X to %d made a difference? But then (not 100% certain, haven't traced back) it appears to have a problem with the %d in the printf "Execution starts..."

And then, there is this (note I took out the '\n' at the end of the 2nd printf):

printf("Running on CPU%d\n",getCpuNum()); /* Initializations */ Next_Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type)); Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type)); //printf("Next_Ptr_Glob=0x%08X, Ptr_Glob=0x%08X\n", Next_Ptr_Glob, Ptr_Glob); printf("Next_Ptr_Glob=%d, Ptr_Glob=%d", Next_Ptr_Glob, Ptr_Glob); // etc. etc

I see the output:
"
Running on CPU0
Next_Ptr_Glob=1879048288, Ptr_Glob=1879048344RAP1
"
before the wild access. So here, the newline seems to make a difference, but appently the wild access comes from a printf call with no arguments, or perhaps the strcpy that immediately proceeds it.

What to make of this information? The results are consistent over repeated runs. Am I chasing red herrings? I have tried to get a more detailed stack trace but again I get slightly lost inside all the library code. The most I can see my code doing is a seemingly normal printf. Thanks for any help or suggestions!
Cancel
Vote up 0 Vote down

Cancel

Reply

Rich Podraza over 12 years ago

Note: This was originally posted on 19th September 2012 at http://forums.arm.com

Two thoughts, probably not useful:

1. flsbuf.o is probably only using the FILE obejct (allocated on the heap) so if it's making wild reads, perhaps the FILE object has been corrupted (by being overwritten?) Maybe try inserting some some heap checking by using '__heapvalid' (but perhaps not using fprintf).

2. If you tend to write 'printf(p)' instead of 'printf("%s", p)' then make sure that the string that 'p' points at doesn't have any (undoubled) '%'s in it.

Can you get a stack backtrace at the point of the wild access?

I tried upping my stack/heap size to 256 MB and still see the wild access. I will look up __heapvalid and try to see if that is helpful. In the meantime, I have tried some different things with the printf statements and am getting different behavior. This is taken from a dhrystone app.

printf("Running on CPU%d\n",getCpuNum()); /* Initializations */ Next_Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type)); Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type)); printf("Next_Ptr_Glob=0x%08X, Ptr_Glob=0x%08X\n", Next_Ptr_Glob, Ptr_Glob); // some code truncated here

The above code only gives me the output "Running on CPU 0" before the access. BUT,

printf("Running on CPU%d\n",getCpuNum()); /* Initializations */ Next_Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type)); Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type)); //printf("Next_Ptr_Glob=0x%08X, Ptr_Glob=0x%08X\n", Next_Ptr_Glob, Ptr_Glob); printf("Next_Ptr_Glob=%d, Ptr_Glob=%d\n", Next_Ptr_Glob, Ptr_Glob); Ptr_Glob->Ptr_Comp = Next_Ptr_Glob; Ptr_Glob->Discr = Ident_1; Ptr_Glob->variant.var_1.Enum_Comp = Ident_3; Ptr_Glob->variant.var_1.Int_Comp = 40; printf("RAP1\n"); strcpy (Ptr_Glob->variant.var_1.Str_Comp, "DHRYSTONE PROGRAM, SOME STRING"); strcpy (Str_1_Loc, "DHRYSTONE PROGRAM, 1'ST STRING"); printf("RAP2\n"); Arr_2_Glob [8][7] = 10; printf("RAP3\n"); /* Was missing in published program. Without this statement, */ /* Arr_2_Glob [8][7] would have an undefined value. */ /* Warning: With 16-Bit processors and Number_Of_Runs > 32000, */ /* overflow may occur for this array element. */ printf ("\n"); printf ("Dhrystone Benchmark, Version 2.1 (Language: C)\n"); printf ("\n"); if (Reg) { printf ("Program compiled with 'register' attribute\n"); printf ("\n"); } else { printf ("Program compiled without 'register' attribute\n"); printf ("\n"); } Number_Of_Runs = 999; printf ("Execution starts, %d runs through Dhrystone\n", Number_Of_Runs);

Gives the output
"
Running on CPU0
Next_Ptr_Glob=1879048228, Ptr_Glob=18799048344
RAP1
RAP2
RAP3

Dhrystone Benchmark, Version 2.1 (Language: C)

Program compiled without 'register' attribute
"
until the wild access. So it seems changing parameter types from %08X to %d made a difference? But then (not 100% certain, haven't traced back) it appears to have a problem with the %d in the printf "Execution starts..."

And then, there is this (note I took out the '\n' at the end of the 2nd printf):

printf("Running on CPU%d\n",getCpuNum()); /* Initializations */ Next_Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type)); Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type)); //printf("Next_Ptr_Glob=0x%08X, Ptr_Glob=0x%08X\n", Next_Ptr_Glob, Ptr_Glob); printf("Next_Ptr_Glob=%d, Ptr_Glob=%d", Next_Ptr_Glob, Ptr_Glob); // etc. etc

I see the output:
"
Running on CPU0
Next_Ptr_Glob=1879048288, Ptr_Glob=1879048344RAP1
"
before the wild access. So here, the newline seems to make a difference, but appently the wild access comes from a printf call with no arguments, or perhaps the strcpy that immediately proceeds it.

What to make of this information? The results are consistent over repeated runs. Am I chasing red herrings? I have tried to get a more detailed stack trace but again I get slightly lost inside all the library code. The most I can see my code doing is a seemingly normal printf. Thanks for any help or suggestions!
Cancel
Vote up 0 Vote down

Cancel

Children

No data