English Amiga Board Amiga Lore


Go Back   English Amiga Board > Coders > Coders. Language

 
 
Thread Tools
Old 23 July 2010, 04:38   #1
NovaCoder
Registered User
NovaCoder's Avatar
 
Join Date: Sep 2007
Location: Melbourne/Australia
Posts: 3,007
[SOLVED] GCC (g++) Memory allocation issues

Ok this is really starting to annoy me now

I'm trying to port this project to 68k (020) using gcc V2.9.5.3 (CubicIDE) and I'm having memory issues. The code is a large C++ project with a mixture of new(), malloc() and calloc().

There seems to be some kind of arbitrary limit of memory that causes the program to crash. The only way I've managed to get it run is to convert all of the calls from malloc()/calloc() to the AllocMem() which I obviously shouldn't have to do.

Currently I've got the compiler setup to store the data as 'FAR', does it need to be set to 'EXTRA FAR' or something silly like that?

I can't be the only one to ever come across this issue

Help!
NovaCoder is offline  
AdSense AdSense  
Old 23 July 2010, 06:20   #2
Leffmann
Leffmann with two n's
Leffmann's Avatar
 
Join Date: Jul 2008
Location: Sweden
Posts: 1,517
The far qualifier is a remnant from the early x86 architectures which used a segmented memory model. The M68K architecture has always used a flat memory model, and the far qualifier is useless here and has no effect on your pointers.

Does the code crash inside the malloc/calloc calls or because you don't check their return values? Or do you mean that you simply run out of memory when you use malloc/calloc instead of AllocMem? If AllocMem works, then why not just use that?

It's possible that GCC's standard library arbitrates calls to malloc/calloc to handle tiny allocations more efficiently, but I think an error of this kind wouldn't have slipped through.
Leffmann is offline  
Old 23 July 2010, 07:58   #3
NovaCoder
Registered User
NovaCoder's Avatar
 
Join Date: Sep 2007
Location: Melbourne/Australia
Posts: 3,007
It's driving me crazy (ok I was already a little crazy before I started Amiga coding but there you go).

My other problem is that I can't really debug it (or at least step-through the code).

The only thing I know so far for sure is:

1) Replacing all the calls from calloc to AllocMem(FAST_MEM) gets it working.
2) The code seems to be run though a number of calloc statements before it blows up (reboots the computer!).

Other people must have had this issue.....I can't be that unlucky

The code doesn't check the return values from the calls to calloc/malloc.

Last edited by NovaCoder; 23 July 2010 at 08:19.
NovaCoder is offline  
Old 23 July 2010, 11:11   #4
phx
Registered User

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 545
Quote:
Originally Posted by NovaCoder View Post
My other problem is that I can't really debug it (or at least step-through the code).
When you get a reproduceable crash you should be able to find the crash location, even without a debugger.

What kind of Guru is it? Illegal instruction (80000003) or memory corrupted (81000005), etc?

Also use Enforcer and MungWall or similar tools to provoke memory failures early, and replace AllocMem/calloc by an own function which checks the return value.

Quote:
1) Replacing all the calls from calloc to AllocMem(FAST_MEM) gets it working.
Without MEMF_CLEAR? That's strange. Rememer that calloc() will return zeroed memory!


Quote:
2) The code seems to be run though a number of calloc statements before it blows up (reboots the computer!).
Oh. So there is no Guru? I guess your program is writing to unallocated memory, or exceeds the limits of the allocated memory chunks.

As stated above, use Enforcer/MungWall. And try to allocate twice the memory requested and see if it changes anything. I guess it's just luck when AllocMem doesn't crash, because the memory is allocated in a different order.
phx is offline  
Old 23 July 2010, 13:28   #5
NovaCoder
Registered User
NovaCoder's Avatar
 
Join Date: Sep 2007
Location: Melbourne/Australia
Posts: 3,007
I've noticed in WINUAE it writes 'BI_TARGETTED' to the command window...not sure if that helps.

I was setting MEMF_CLEAR when I called AllocMem(FAST_MEM) eg (AllocMem(FAST_MEM|MEMF_CLEAR)

Do you think that could have made a difference?
NovaCoder is offline  
Old 23 July 2010, 23:19   #6
jotd
Cat freak
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 43
Posts: 859
It is possible that your app is broken (using free twice on a zone or something like that) and there's different behaviour between AmigaOS calls and gcc calls.

Have you used memminister to ensure that all memory is freed on exit? Maybe some free() fails in the way and corrupts the memlist.
I've worked a lot with gcc (on Linux/Windows). When you're lucky, it crashes in the free() call. When you're not lucky it crashes in the next malloc()!!
jotd is offline  
Old 26 July 2010, 02:00   #7
NovaCoder
Registered User
NovaCoder's Avatar
 
Join Date: Sep 2007
Location: Melbourne/Australia
Posts: 3,007
Ok I think I've found the problem at last.

In parts of the code it calls calloc() but passes in zero for the number variable (the first parameter). In other implementations this would just result in no memory being allocated and calloc() would simply return NULL but in gcc 68k it blows up!

Oh well, glad I've finally figured this one out after all this time.
NovaCoder is offline  
Old 26 July 2010, 06:15   #8
matthey
Registered User
 
Join Date: Jan 2010
Location: Kansas
Posts: 431
The Amiga built in memory allocation functions are more friendly. They handle 0 bytes just fine. It wouldn't be that difficult to switch to them. exec/AllocVec() is especially easy to use. It tracks the size of the allocation making it easier to use than exec/AllocMem().

It's probably more polite to allocate without the MEMF_FAST flag to allow for users with no fast ram and that run out of fast mem. Just set MEMF_CLEAR if you want the memory cleared or MEMF_ANY (0L) if you don't need it cleared.
matthey is offline  
Old 26 July 2010, 23:26   #9
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 197
reminds me of that bernd has built a workaround for something like this into his ixemul.lib. mem allocations of 0 seem to be quite a frequent bug in nix progs.
wawa is offline  
Old 27 July 2010, 13:02   #10
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 39
Posts: 14,453
malloc and friends are allowed to return either NULL or some "dummy" pointer that free() accepts when allocation size = zero. (afaik zero size was originally undefined)

Quote:
I've noticed in WINUAE it writes 'BI_TARGETTED' to the command window...not sure if that helps.
This only means program did something seriously bad and JIT got confused. (JIT and debugging is not very good combination)
Toni Wilen is offline  
Old 06 January 2012, 23:08   #11
tygre
Returning fan!

tygre's Avatar
 
Join Date: Jan 2011
Location: Montréal, QC, Canada
Posts: 199
Question IXEmul: "realloc: start of block corrupt"

Hi there!

In my never-ending quest to recompile THTTPd v2.21b with PHP v4.2.3, I succeeded in compiling the beast but I got from times to times this error from IXEmul (v63.1): a dialog box opens stating "realloc: start of block corrupt" with only one button "Abort". When I click "Abort", I got the requester from the OS stating that the "memory header not located"...

Could anyone guide me in understanding and fixing this problem. (I compile PHP and THTTPd without any optimisations.)

Thanks in advance!
Tygre

Last edited by tygre; 07 January 2012 at 02:39. Reason: Typos
tygre is offline  
Old 07 January 2012, 02:35   #12
tygre
Returning fan!

tygre's Avatar
 
Join Date: Jan 2011
Location: Montréal, QC, Canada
Posts: 199
Here are some more details and a code snippet illustrating my problem:

Code:
#include <stdio.h>
int main()
{
    printf("Hello World!\n");
    void* ptr = malloc(1000);
    // realloc(ptr, 10000);
    free(ptr);
    printf("Goodbye.\n");
    return(0);
}
With IXEmul v63.1 and v48.0, the code above works as expected with the commented line. If the line is uncommented, the IXEmul library reports this error "realloc: start of block corrupt". I simply compile this code using:

Code:
m68k-amigaos-gcc alloc.c -o alloc
Is this a known problem? Did anyone encounter it before?

I guess I will have to "rewrite" realloc in PHP using malloc and memcpy...

Please, let me know what you think!
Tygre

Last edited by tygre; 07 January 2012 at 02:43. Reason: More details; typos
tygre is offline  
Old 07 January 2012, 04:54   #13
Leffmann
Leffmann with two n's
Leffmann's Avatar
 
Join Date: Jul 2008
Location: Sweden
Posts: 1,517
Never seen that before, but one cause could be that you may be freeing the wrong memory; realloc() returns a new pointer which you must always accept, because there's no guarantee that the new block will start at the same address.

(also, if you want to be really compliant then you should include stdlib.h since that's where the memory allocation functions are declared)
Leffmann is offline  
Old 07 January 2012, 15:47   #14
tygre
Returning fan!

tygre's Avatar
 
Join Date: Jan 2011
Location: Montréal, QC, Canada
Posts: 199
Thank for your answer Leffmann... I did some more tests and my real problem is that realloc does not always cause this problem... it can work fine for several runs and then, all the sudden, boom So it is hard to track what is happening...

Could it be a wrong combination of GCC and IXEmul?

My GCC says:

Code:
Reading specs from /usr/local/amiga/lib/gcc/m68k-amigaos/3.4.0/specs
Configured with: ../gcc-3.4.0/configure --prefix=/usr/local/amiga --target=m68k-amigaos --enable-languages=c,c++,objc --enable-haifa --enable-sjlj-exceptions --disable-shared --disable-libstdcxx-pch
Thread model: single
gcc version 3.4.0
(I found it Zerohero's web site.)



PS. I found a thread about a (maybe) similar problem... unfortunately, it states that IXEmul should work find with allocating a size of zero...

Last edited by tygre; 07 January 2012 at 16:08.
tygre is offline  
Old 07 January 2012, 15:59   #15
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 39
Posts: 14,453
Your problem (as was already said) is wrong usage of realloc(). It may return original address or it may return new address. Depends on available memory, memory fragmentation and so on..

Also note that realloc() can fail.
Toni Wilen is offline  
Old 07 January 2012, 16:24   #16
tygre
Returning fan!

tygre's Avatar
 
Join Date: Jan 2011
Location: Montréal, QC, Canada
Posts: 199
Thanks Toni but my real problem is that the crash occurs "randomly"...

I am trying to port THTTPd, which works fine on Unix and which has already been ported by LouiSe (but I must "re-port" it because of changes that I will make to it) so what could be the cause of the crashes?

Is Unix more lenient than AmigaOS? If so, how come would LouiSe's port work fine? Sorry for such general questions but I could use any hints right now...

PS. And again thank to you and Leffmann for pointing out my mistakes in my code snippet that should be:

Code:
#include <stdio.h>
#include <stdlib.h>
int main()
{
    printf("Hello World!\n");
    void* ptr = malloc(0);
    ptr = (void *) realloc(ptr, 100);
    free(ptr);
    printf("Goodbye.\n");
    return(0);
}
tygre is offline  
Old 07 January 2012, 16:26   #17
tygre
Returning fan!

tygre's Avatar
 
Join Date: Jan 2011
Location: Montréal, QC, Canada
Posts: 199
Sorry for kind of duplicating this thread... I started dumbly a thread about what I realise is a similar problem...
tygre is offline  
Old 07 January 2012, 16:41   #18
prowler
Global Moderator

prowler's Avatar
 
Join Date: Aug 2008
Location: Sidcup, England
Posts: 9,701
Quote:
Originally Posted by tygre View Post
Sorry for kind of duplicating this thread... I started dumbly a thread about what I realise is a similar problem...
Threads merged.
prowler is offline  
Old 07 January 2012, 16:53   #19
tygre
Returning fan!

tygre's Avatar
 
Join Date: Jan 2011
Location: Montréal, QC, Canada
Posts: 199
Thanks! You are too fast
tygre is offline  
Old 07 January 2012, 18:53   #20
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 39
Posts: 14,453
Tried Mungwall or Enforcer to debug memory related errors?
Toni Wilen is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
"special" chip-mem allocation 68K-ASM Herpes Coders. System 4 13 June 2013 12:42
Some issues with CD32 and WHDLoad [Solved] DarthKaal support.FS-UAE 11 05 January 2013 13:08
PCMCIA Memory Issues moora support.Hardware 8 25 January 2012 19:59
Blizzard Turbo Memory - SMD memory chips doesn't work sanjyuubi Hardware mods 5 26 May 2010 16:40
Blizzard 1260 memory issues papa_november support.Hardware 10 06 August 2009 17:37

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 07:40.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
Page generated in 0.27259 seconds with 11 queries