the old "#undef free" trick

I was reluctant to mention that as I am unfamiliar with the effects in a mingw environment.

(By undeffing free, we get to call the free() that we want, not the the free() that perl defined for us.)

It would be interesting to see the /E output after doing that?

I'm guessing that it gives your the CRT free(), but that then brings up the question:

If you need the CRT free(), what/where/how was the thing being freed, allocated?

I suspect you may have been on the right lines in your other post; and the problem is that actually, the OP is freeing the wrong thing. And the fact that by doing so using the CRT free() doesn't cause a crash is simply luck.

Yes, this makes the trick. After changing source code to


#include <pthread.h>
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
#include "ppport.h"

#undef free
#undef malloc

void *thread(void *arg) {
    char *msg = (char*)arg;
    printf("thread: %s\n", msg);
    free(msg);
    return NULL;
}

MODULE = My    PACKAGE = My

void
test_thread(char *msg)
    PPCODE:
        char *thread_arg = malloc((strlen(msg)+1)*sizeof(char));
        strcpy(thread_arg, msg);
        pthread_t tid;
        pthread_create(&tid, NULL, thread, (void*)thread_arg);
        
        void *rv;
        pthread_join(tid, &rv);
[download]

I have no crashes more! And gcc -E says malloc() is malloc() and free() is free().

Now I am wondering is this trick should be done only on Windows?

> the OP is freeing the wrong thing
Why you think so? Freeing memory after malloc(), even in the other thread doesn't looks wrong for me.

Yes, this makes the trick. After changing source code to

#include <pthread.h>
 #include "EXTERN.h"
 #include "perl.h"
 #include "XSUB.h"
 #include "ppport.h"

 #undef free
 #undef malloc
[download]

You'll get away with that as long as you do not attempt to pass anything you malloc() to perl.

When it gets interesting is when you try to free() something allocated by Perl within your C/XS code; or vice versa.

As I mentioned above, under iThreads, different pools of memory are used for each (perl instantiated) thread via the custom allocator.

Attempt free something allocated by the CRT (ie. by you in your XS code with #undef malloc) and then free it using the custom allocators free() (eg. by passing it into Perl and then letting it go out of scope) and you'll probably get the infamous: "free to wrong pool" message.

Attempt to free something allocated by that allocator using the CRT free() and you'll blow up bigtime.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

It would be interesting to see the /E output after doing that?

It's about a megabyte of output ... too big for my scratchpad, I think ??

If you need the CRT free(), what/where/how was the thing being freed, allocated?

Good question. I put:

#ifdef malloc
printf("\nmalloc has been defined to something\n");
#endif
[download]

just prior to the malloc() call, and it confirmed that malloc had, indeed been defined to something.
Interestingly, I can #undef malloc prior to the malloc() call, and that has no effect on any aspect of the behaviour of the script (AFAICT).
I don't think I really want to delve into those convolutions you mentioned earlier ;-)

I suspect you may have been on the right lines in your other post

I've just checked that char*msg, char*arg and char*thread_arg (which is the arg that was originally malloc()'d) all point to the same location - and they do.
IIUC (not guaranteed), that means you can free the memory by calling free() on either one of the three.

Cheers,
Rob

It's about a megabyte of output ... too big for my scratchpad, I think ??

In general, if you move to the end of the file and then back up, you can isolate the few dozen lines that come from your files and ignore the bulk of the stuff that comes from the included header files.

But it's not necessary. The OP seems happy with the solution and its caveats.

I've just checked that char*msg, char*arg and char*thread_arg (which is the arg that was originally malloc()'d) all point to the same location - and they do. IIUC (not guaranteed), that means you can free the memory by calling free() on either one of the three.

Provided it was allocated using the crt malloc, it'll be fine. (The OPs use of #undef malloc should guarentee that.)

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.