Re^8: XS: free() outside of the main thread causes crash on Windows

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.

Comment on Re^8: XS: free() outside of the main thread causes crash on Windows Download Code

Replies are listed 'Best First'.
Re^9: XS: free() outside of the main thread causes crash on Windows by BrowserUk (Patriarch) on Sep 25, 2014 at 10:04 UTC
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.	[reply] [d/l]
Re^10: XS: free() outside of the main thread causes crash on Windows by OlegG (Monk) on Sep 25, 2014 at 10:14 UTC
I understand that. And in my real code i'll undef this temporarily and only to manipulate pure C structures.	[reply]
Re^11: XS: free() outside of the main thread causes crash on Windows by BrowserUk (Patriarch) on Sep 25, 2014 at 11:20 UTC
And in my real code i'll undef this temporarily and only to manipulate pure C structures. The way I did it was to put `crt(re\|C\|M)alloc()` & `crtFree()` functions in a separate file with the appropriate `#undef`s. 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.	[reply] [d/l] [select]