I also looked on github. deleting that file is basically a non-answer. What needs to happen is there should not be two pieces memory management code. It has to be one or the other, and not both.
@ajk_, I know what needs to happen, but if the solution to this issue were so simple it would have been already implemented.
The one in stdlib should be eliminated? The one in the arduino lib? I don't know :(
and I replied with the short answer to give you a rapid workaround, but I also sent you the link to the original issue because the long answer is really long.
Shortly, the facts are:
1) Arduino IDE is shipped with avr-gcc 4.3.2.
2) The 4.3.2 has a buggy malloc() implementation: it rarely fails with sketches that make intensive use of malloc() and free() due to memory fragmentation issues.
3) We provided a fixed malloc.c on Arduino core that fixes the issues in 2) look at http://code.google.com/p/arduino/issues/detail?id=857
4) Using 3) will not allow a 3rd party library (like xmem) to redefine malloc() and free()-
5) Upgrading the avr-gcc may solve the issue 2) but introduce other subtle and painful issues: https://github.com/arduino/Arduino/issues/1208
Correct! And the question is will it be fixed? This is something that is pretty important, and actually fundamental if you think about it.
More to the point HOW to do a proper fix needs to be discussed and settled.
I'm here to help, offer code and suggestions or anything else within my means.
As far as xmem, it doesn't redefine malloc and free at all, it simply re-points where the heap is located. Since it does an include, and there are two memory management codes, you get a conflict.
I hack Glibc a lot for my own stuff, and my own ports, cross compiles, etc, so I kind of know my way around the whole code source, how to build, etc. I'm not a noob... I've been doing open source for 20 years, including Linux Kernel.
Anyway, note that GCC != Glibc. You can replace Glibc at any time you like, and use almost any GCC version. I do this sort of thing all the time. :-) it is rare for there to be a problem with a newer/better Glibc, and if there is, that information is usually available.
I think, If Glibc routines are buggy, then the answer is to not include it, but include instead a better replacement. Is there some incompatibility problem with the one in the Arduino libs? Shouldn't be... malloc and friends are dead simple.
I wrote a set of malloc/free/realloc stuff for RAM starved 8bit machines in the past, and it is very fragment resistant, in ANSI C. and highly portable. That could be an additional help if you want the code, I can release it openly since I wrote it.
Basically I'm not looking for a work around or a rapid hack or fix at this time.
I'm more concerned with the next release, and I would like to offer a hand/mind.
It is good to see that this bug is being actively discussed, but it is time to move forward.
Simply, let's think up a solution, agree on it, and fix the problem. If that means gutting the one from Glibc, I'm good with that, since it has issues anyway. What is the solution done in 1.0.3? Does that contain bugs in MM too? If it does, then that really explains the odd occasional lockup and random restart problems that I have seen. :D