How NOT to write a shared library

[LaRoza]

Really? How far did it make it before that happened? Can you try it with a "long long unsigned int" instead of a regular int?

I let the program run again, and dumped the results to a text file. I killed the program when it was started slowing down my computer. The text file is over 500 MB and I can not post it (or even open it).

It seems the if condition is never met, but the memory is never allocated.

[DavidBell]

you have only one memory, and when full, it is full.

But this is not the case.

If you ask for one byte and malloc says no, well then you really are in trouble. But it is more likely it is going to be refusing requests for Mbytes. If it says no in that case it doesn't mean memory is empty, just that there's not as much as you asked for. So then you cancel the big memory operation and run cleanup code

I'm totally with j_g on this, libs should never terminate their calling app. The way it it is supposed to work is ...

* app calls lib function

* lib function fails due to OOM or whatever. lib doesn't kill parent app, it sends back an 'operation failed' return code, often with extra info about why.

* app checks return code, if failed cleans up, alerts user etc, user kills a few processes that they decide are not critical, ....

That way between lib, app and user things like unsaved work don't get destroyed without warning.

DB

[DavidBell]

I got an infinite loop (that I killed). It put "Allocated and freed 0 MB" for a very long time.

Did you copy word for word?

Sounds like you didn't initialise

#define MEGABYTE 1024*1024

and

int count = 1;

[LaRoza]

Did you copy word for word?

Sounds like you didn't initialise

#define MEGABYTE 1024*1024

and

int count = 1;

Yes.

I am puzzled by the behavior.

[Wybiral]

Yes.

I am puzzled by the behavior.

Since you got a bunch of 0's for the count, I'm willing to bet it had nothing to do with malloc. It was more likely that malloc wasn't reporting an error because it was only having to allocate 0 bytes (and it gladly did so, lol)

At first I suspected it to be an integer overflow. Such as:

#include <stdio.h>

int main(int argc, char *argv[])
{
    int count = 1;
    while(count != 0)
    {
        count *= 2;
        printf("%d\n", count);
    }
    return 0;
}

But thinking about it, the odds that you had enough memory for it to get that far are pretty unlikely.

Try adding a "count > 0" to the while loop and see when it exits.

[samjh]

I've just tried Wybiral's code and get the expected behaviour.

Allocated and freed 1 MB
Allocated and freed 2 MB
Allocated and freed 4 MB
Allocated and freed 8 MB
Allocated and freed 16 MB
Allocated and freed 32 MB
Allocated and freed 64 MB
Allocated and freed 128 MB
Allocated and freed 256 MB
Allocated and freed 512 MB
Allocated and freed 1024 MB
Sorry Dave... I can't do that.

LaRoza, try cutting and pasting Wybrial's code instead of retyping it. Otherwise perhaps re-install gcc and try again?

[j_g]

My experience in writing shared libraries is almost nil.

I would have thought that the correct way to handle errors in any library would be for the offending function to return an error code, which should then be propagated back to the calling application, and let the application decide what to do.

And you thought correctly. You've already gotten a head start upon certain people who have written shared libs, because you'll be doing it correctly from the beginning.

[LaRoza]

LaRoza, try cutting and pasting Wybrial's code instead of retyping it. Otherwise perhaps re-install gcc and try again?

I did copy and paste. Looking for other solutions now, report back later.

[LaRoza]

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define MEGABYTE 1024*1024

int main(int argc, char *argv[])
{
    void *myblock = NULL;
    int count = 1;

    while(count != 0)
    {
        myblock = (void *) malloc(count * MEGABYTE);
        if (!myblock) break;
        memset(myblock, 1, count * MEGABYTE);
        free(myblock);
        printf("Allocated and freed %d MB\n", count);
        count *= 2;
    }
    printf("Sorry Dave... I can't do that.\n");
    return 0;
} 

Allocated and freed 1 MB
Allocated and freed 2 MB
Allocated and freed 4 MB
Allocated and freed 8 MB
Allocated and freed 16 MB
Allocated and freed 32 MB
Allocated and freed 64 MB
Allocated and freed 128 MB
Allocated and freed 256 MB
Allocated and freed 512 MB
Allocated and freed 1024 MB
Allocated and freed 2048 MB
Allocated and freed 4096 MB
Allocated and freed 8192 MB
Allocated and freed 16384 MB
Allocated and freed 32768 MB
Allocated and freed 65536 MB
Allocated and freed 131072 MB
Allocated and freed 262144 MB
Allocated and freed 524288 MB
Allocated and freed 1048576 MB
Allocated and freed 2097152 MB
Allocated and freed 4194304 MB
Allocated and freed 8388608 MB
Allocated and freed 16777216 MB
Allocated and freed 33554432 MB
Allocated and freed 67108864 MB
Allocated and freed 134217728 MB
Allocated and freed 268435456 MB
Allocated and freed 536870912 MB
Allocated and freed 1073741824 MB
Allocated and freed -2147483648 MB
Sorry Dave... I can't do that.

I have 2.5 GB of RAM. Explain this please....

[Wybiral]

I have 2.5 GB of RAM. Explain this please....

Ohhh... It's because malloc only accepts "size_t" bytes. On my computer, "size_t" is limited to (2 ^ 32) - 1 or 4294967295. The multiplication in the parameter must be overflowing it and it will never reach more than 4 gb (which your ram + swap is apparently covering). Crazy, I don't think it's possible to allocate more than that much contiguous space.

EDIT:

You could try allocating 2-3 gb of memory before the loop if you want to test whether or not it will catch the NULL return.