As Steve Franks wrote: > FYI, We are having serious issues (reboots, etc) on the project that > generated this bug report, and cannot appear to find any > pointer/bounds issues that would cause that type of behavior.
However, just to remind you, the subject of this bug report is *solely* to fix the slightly misleading picture in the docs that made you think __malloc_heap_end were an address when it is actually a variable pointing to an address. > Of course, we are building on an arbirary version of avr-libc from > cvs (that we pulled in to fix the avr6/sprintf bug), so maybe some > other isses are there due to that. At least the malloc() stuff has not been changed in ages (more than 1.5 years ago). Alas, there's not much I could see to help you debugging that. Did you try analyzing the stack/heap usage? (By filling the entire area with a pattern initially, and then looking how much of that pattern has been overwritten.) -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ AVR-libc-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
