Pages: [1]   Go Down
Author Topic: malloc problem on AVR, Arduino 1.5.2  (Read 3391 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 1
Posts: 48
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

When using xmem library for avr on mega, there are two conflicting malloc implementations.
The problem also crops up on a few other projects I am working on as well.

The one in stdlib should be eliminated? The one in the arduino lib? I don't know smiley-sad
Here is some typical output:

/home/ajk/arduino-1.5.2/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../avr/lib/avr51/libc.a(malloc.o):
/In function `malloc':
/home/paul/avr-libc-1.6.4/avr/lib/avr51/../../../libc/stdlib/malloc.c:78:
/multiple definition of `malloc'
core.a(malloc.c.o):/home/ajk/arduino-1.5.2/hardware/arduino/avr/cores/arduino/malloc.c:281:
first defined here
/home/ajk/arduino-1.5.2/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../avr/lib/avr51/libc.a(malloc.o):
In function `free':
/home/paul/avr-libc-1.6.4/avr/lib/avr51/../../../libc/stdlib/malloc.c:195:
multiple definition of `free'
core.a(malloc.c.o):/home/ajk/arduino-1.5.2/hardware/arduino/avr/cores/arduino/malloc.c:281:
first defined here

 smiley-cry

One of them has to go away to eliminate the conflict.
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 1
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I've encountered similar conflicts with malloc definitions in 1.5.2.  Reverting to previous release compiles without issue.

Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr5/libc.a(malloc.o): In function `malloc':
/Users/cs/Developer/Hardware/AVR-USB/AVRMacPack/buildtmp.nobackup/avr-libc-1.6.4/avr/lib/avr5/../../../libc/stdlib/malloc.c:78: multiple definition of `malloc'
core.a(malloc.c.o):/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/avr/cores/arduino/malloc.c:82: first defined here
/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr5/libc.a(malloc.o): In function `free':
/Users/cs/Developer/Hardware/AVR-USB/AVRMacPack/buildtmp.nobackup/avr-libc-1.6.4/avr/lib/avr5/../../../libc/stdlib/malloc.c:195: multiple definition of `free'
core.a(malloc.c.o):/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/avr/cores/arduino/malloc.c:194: first defined here
Logged

Offline Offline
Newbie
*
Karma: 1
Posts: 48
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Still no news if this is fixed yet?  smiley-surprise
_Will_ it be fixed?  smiley-razz
Logged

Forum Administrator
Milano, Italy
Offline Offline
Sr. Member
*****
Karma: 23
Posts: 292
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Short answer: to solve your issue remove this file

hardware/arduino/avr/cores/arduino/malloc.c

(beware that this will make your library working but can create other subtle failures on Strings for example).

Long answer: http://code.google.com/p/arduino/issues/detail?id=857
Logged

C.

Offline Offline
Newbie
*
Karma: 1
Posts: 48
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Germany
Offline Offline
Full Member
***
Karma: 10
Posts: 230
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
May with some define lines it can be solved
Logged

Forum Administrator
Milano, Italy
Offline Offline
Sr. Member
*****
Karma: 23
Posts: 292
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.

You asked:

The one in stdlib should be eliminated? The one in the arduino lib? I don't know smiley-sad


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

Logged

C.

Offline Offline
Newbie
*
Karma: 1
Posts: 48
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.

You asked:

The one in stdlib should be eliminated? The one in the arduino lib? I don't know smiley-sad


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.

Some background:
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. smiley-grin

Logged

Forum Administrator
Milano, Italy
Offline Offline
Sr. Member
*****
Karma: 23
Posts: 292
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.

very good smiley

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. smiley-grin

1.0.3 does have the bug.
1.0.4 have a patched malloc.c in the Arduino core.

note that newer libc fixes MM, but introduces other bugs so you can't take it as a whole. It's all written in the discussions I linked on my previous post, please, don't let me repeat everything.

If you have a better solution, the right place to discuss it is here:
http://code.google.com/p/arduino/issues/detail?id=857

I'll be very happy to examine it and eventually merge it upstream. Thanks!
Logged

C.

Offline Offline
Newbie
*
Karma: 1
Posts: 48
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I'll review what's over there, and lend a hand over the next few days.
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 32
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Did this work get anywhere?  I've got a RuggedCircuits QuadRAM board, and i've tried to use XMEM and XMEM2 to expand into the extra memory, but i can't get anything to compile.  Removing the existing files is going to be tricky, as I have 2 builds of my project, one with extra ram and one without.

Apologies, i'm a bit "high level" and haven't delved into the details of the compiler before.

I'm using a Mega 2560, Arduino 1.5.2 and the QuadRamboard (but only need the first bank really)

Mark B
Logged

Offline Offline
Newbie
*
Karma: 1
Posts: 48
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Yes, it has been fixed for quite some time.
You might want to update xmem2 as well... there is some really cool goodness within it now that you can enable-- real preemptive multitasking with 16 separated 32KB work areas for malloc and stack.

 smiley-cool

What OS are you using? I know that it compiles fine on MacOS and Linux...
If you read in most of library sources, you'll see the following:

"IMPORTANT! PLEASE USE Arduino 1.0.5 or better!"

 smiley-roll

I forgot to add that in this one, and I will.
« Last Edit: August 06, 2013, 02:08:37 am by ajk_ » Logged

0
Offline Offline
God Member
*****
Karma: 26
Posts: 610
Always making something...
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Have you tried using the latest nightly build?

This particular problem has (probably) already been solved.  Obviously you saw the duplicate symbol error and believe the problem is 2 copies of malloc.  But that's not a complete understanding of the problem.  The real reason is (probably) due to the copy of malloc.c in 1.5.2's core library lacking certain avr-libc tuning parameters.  I know, because I'm the one who made that earlier attempt, which omitted those seldom-used parameters.  That turned out to be a mistake, because while they're not often used, some programs obviously do depend on them.  That causes the linker to try to bring in both copies, which gives you a misleading error message.

Christian fixed this problem many months ago, by bringing in a newer version of malloc which includes those seldom-used avr-libc tuning features.  So before making a lot more noise based on the old 1.5.2 release, the very least you could do is give the latest nightly build a try.

I'm pretty sure the nightly build will solve your problem, as will 1.5.3 and future releases.
Logged

Pages: [1]   Go Up
Jump to: