in reply to Re^4: XS: free() outside of the main thread causes crash on Windows
in thread XS: free() outside of the main thread causes crash on Windows

But yes perl does redefine these things, ...

The problem is that those also get redefined at various points. See win32\win32iop.h. Sometimes, multiple times depending upon where you are in the source code.

And the allocator used under Windows is a custom allocator. See win32\vmem.h. (Though that is also dependent upon build-time options...)

It's all very convoluted to work out exactly what is being compiled.


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.
  • Comment on Re^5: XS: free() outside of the main thread causes crash on Windows

Replies are listed 'Best First'.
Re^6: XS: free() outside of the main thread causes crash on Windows
by syphilis (Archbishop) on Sep 25, 2014 at 08:54 UTC
    The problem is that those also get redefined at various points

    Aaaah ... it seems to be the old "#undef free" trick that's needed here.
    The following rendition works fine for me on Strawberry:
    void *thread(void *arg) { #undef free char *msg = (char*)arg; printf("thread: %s\n", msg); free(msg); return NULL; }
    You can probably disregard my other post of a few minutes ago.

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

    Cheers,
    Rob
      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.


      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.
        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);
        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.
        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
        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