Weird, C string. Crashes on m68k, works on MOS

[asrael22]

Hi.

I've written a small cmd line utility on MorphOS.
It deals quite a lot with strings, strcpy, strcat, sprintf, etc.
I compile it with GCC on MorphOS. It runs fine there. Not only on quick tests, but running it for days.

On AmigaOS 3.9 however, the same sources, compiled with VBCC crash on a couple of places.
I could partly narrow it down to allocating dynamic memory instead of using stack data. But I'm not sure if it's that.

I've tried to create isolated tests for specific units. But I can't really figure out what's wrong.

Are there any debugging tools on AmigaOs I could give a try?
Are there any best practices for using stack memory vs. dynamic allocations (say for size of 1 to 32 kB)?
What about sprintf et al., it it save to use?



Manfred

[asrael22]

An AmigaOs binary typically has only 4K of stack. Thus, whatever object requires a substantial amount of stack, put it on the heap. As a rule of thumb: If it's longer than 256 bytes, allocate it.

OK. What happens if there is not enough stack space available?

I was reading that memory management on AmigaOS doesn't defragment memory and thought that allocations, if there are many over time, will heavily fragment memory. But for small allocations, a few kB there should always be continuous memory.


Manfred

[asrael22]

Are you sure it still doesn't do something illegal, even though it doesn't crash? I'd check it with the Wipeout program to see if it trashes memory or so.

I'd check it like this:
1) Launch SDK:Tools/logtool
2) Run SDK:Tools/Wipeout
3) Test your program and see if you get anything suspicious to the logtool window

Thanks, I'll try those tools.


Manfred

[asrael22]

Yes. However, for generic C programs, the malloc() implementation of the standard C library will typically use some sort of memory pools to minimize the effect. If you do not want to use malloc(), consider using the memory pools exec provides.

OK. I'm using AllocVec/FreeVec. So I should be using either AllocPooled or malloc (because it does it already).


Thanks,
Manfred

[asrael22]

OK. Another question regarding AllocPooled.

AllocPooled doesn't track the allocated size.
So, what's your advice for how to handle that, say, if the allocation has taken place in some function and the caller is responsible for freeing.
Would I pass an output parameter to the function that should be filled with the allocated size, or?


Manfred

[asrael22]

So, thanks for your answers.
I'm now trying to add more fine grained test options, like allowing each .c file execute the main() method with test options.
Hope to have some more time on the WE.

Manfred

[asrael22]

So I've narrowed it down to this one, which is weird:

Code: [Select]

char* ConvertString2HexString(char *string, long len, char *outHex) {
printf("string len: %ld\n", len);
return string;
}

int main(void) {
char foo[] = "This is my way to say hello!";
long len = strlen(foo);
printf("len of foo: %ld\n", len);
char hexOut[len*2+1];

ConvertString2HexString(foo, len, hexOut);

return 0;
}


This code when compiled on Amiga with VBCC 0.9f gives me this output:
len of foo: 28
string len: 7168


Compiling this on macOS (on some C compiler which is used by Xcode) I get:
len of foo: 28
string len: 28


So, what the heck?

Obviously when using this string len in real it goes far beyond the real string length and overrides some other memory.


Manfred

[asrael22]

Compiling this with GCC 2.95 (which doesn't support C99, so I've swapped the printf line later in the source).
I'm, also getting:
len of foo: 28
string len: 28


So WTF, is there something wrong with VBCC?

[asrael22]

While correct, it is probably worth noting what it does: a) it creates an array of characters, and b) it copies the string from the right into the array just created. While this might be just what you want, let me note that this is different from

Code: [Select]


const char *foo = "This is my way to say hello!";

which omits the copy and just keeps the pointer to the string. Note that the type of the right hand side is "const char[]", not "char []".

I just want a string. Then I guess the pointer version is better suited.
This was just to create a snipped to reproduce the error.
In the real version that string comes from the serial device.

My pure C programming is more than 10 years ago. Since then I developed in higher abstracted languages.
So I have to adapt a bit to the C details.

Well, as you just found out, VBCC does not support VLAs correctly, even less so if they are defined in the middle of a function block. Yes, it's a violation of the C99 standard, so a compiler defect. However, as stated above, I would avoid C99 features in first place in Amiga programs as only few compilers support them, and even less support them correctly, as you have just found out. (-:

What most likely happened is that VBCC got completely lost in its stack frame, i.e. the stack offset of "len" changed in the middle of the function, apparently an effect the code generator did not properly take care of.
%&$#?@!%&$#?@!%&$#?@!%&$#?@! happens if you depend on exotic language features.

I guess I'll report that to Frank Wille and/or Volker Barthelmann.
VBCC only supports a subset of C99, maybe I ran into something that isn't supported.

Since I'm now basically back porting this program from MorphOS where you have GCC 4 and 5 it might be a good idea to stick to C90 to have as much code combatibility as possible between the Amiga OS flavours.


Manfred