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

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

Comment on Re^8: XS: free() outside of the main thread causes crash on Windows Select or 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 11:26 UTC
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 charmsg, chararg 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.	[reply] [d/l]

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 11:26 UTC

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.

[reply]
[d/l]