Dear Mike,
in message 20040209141354.93048.qmail@web40112.mail.yahoo.com you wrote:
I am suspicious of the way memory was initially allocated for the heap. I'm not 100% sure that SDRAM works reliably, but it does boot and run a different version of Linux with no problem. One
OK, this should be pretty save, then.
thing, the version of PPCBoot that I have appears to have been written to utilize all 4 processors, while I am only using 1 CPU.
Ummm.. what do you mean about "utilize all 4 processors"? U-Boot / PPCboot is strictly single-tasking, so what are the other processors used for?
I have lots more info from putting nasty printf's all over the malloc code. If I still can't figure it
I think this will not lead anywhere. Probably you are just hunting down post-mortem symptoms.
out, I'll send the modified source and the trace from its execution.
Oh no, please not. The problem is most definitely somewhere else.
These large sizes for victim->size really concern me. I think that if I can figure out why the victim->size goes so astronomical then I will have found the culprit. I was hoping that maybe somebody had seen this problem before.
Check your memory map, stack depth, stack overruns (or underruns) in your private code, etc. I tend to believe that you either corrupted the malloc internal data and/or the stack somehow.
I just work up, its 7:08AM in Denver. It will be
7 am? What a lousy time to get up ;-)
PS: I LOVE the sig on your message, Wolfgang!
:-) Just never mention it to the manager or the customer ...
Best regards,
Wolfgang Denk