We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hmm - when I see this normally on my platforms it's because I've given printf a corrupt pointer to print as a string or something like that.*EDIT* One other thought is that printf can sometimes use quite a bit of stack (not sure how your version is implemented), so might be worth checking your available stack size and seeing if you underflow the low extent.
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?
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
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);
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
This continues to smell like heap corruption.How are you setting the heap boundaries? And to what values?More random thoughts:[] 256MB should be plenty of heap (unless there's been a lot more allocation that is shown)[] What other code is running before the first printf? Any special startup code or just the standard library startup?[] Are the values printed for Next_Ptr_Glob and Ptr_Glob reasonable? (that is, within you heap and not within your globals or stack) It's good that they are multiples of 8.[] stdout is probably line buffered so flsbuf will be called every "\n" (and every buffer, maybe 512 characters) which explains a bit why changing the format strings changes the timing of the wild access.[] the first printf (or puts, etc.) will cause a buffer for stdout to be created (via malloc)[] if the "%x"s that you changed to "%d"s are the only "%x"s then the main effect will be that image code gets smaller (possibly affecting the globals and heap base) because the formatting code for %x can be removed. Also, of course the contents of the buffer are different after the printf.It's hard to say if tracking down the problem will ultimately be worthwhile, but if I was in your position I'm the sort of person that tends to get obsessed by this sort of thing until I understand it. Changing stdout to unbuffered might possibly avoid the problem (like mapping in the low memory) but it might just come back in some worse way.