I think that the problem is likely that malloc has been redefined by the Perl/XS headers and the Perl code that gets called is trying to access the perl thread context for the "current" thread. Which of course doesn't exist because the thread was not created by Perl.
See Re: Win32::Internet crash, XS, callbacks, perl stack & context, windows api, interpreter thread safety, 1 perl, many C threads by windows for previous related discussion on the problem.
See also Perl crash during perl_clone for a long and twisty thread where I worked through the same problem to a successful conclusion.
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] |
Another thought. If you add #undef malloc just prior to your use of malloc, you may find that the code will run without immediately crashing. But I make no claim that you won't run into similar problems later on.
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] |
add #undef malloc just prior to your use of malloc
Ooow .... I like *that* idea :-)
I've actually placed the '#undef malloc' at the very start of the C code in that script, and the script now runs fine.
Beyond that, nothing has yet been established. Now it's just a matter of seeing whether the same approach can help with PDL (which is where the actual problem that prompted this thread lies.)
Cheers,
Rob
| [reply] |
Ooow .... I like *that* idea :-) I've actually placed the '#undef malloc' at the very start of the C code in that script, and the script now runs fine.
I've had some success with doing that to avoid PerlAPI interfering in stuff that is none of its business.
But be careful. You can find yourself in the 'multiple C runtimes' trap passing pointers allocated by one to another to be freed with various possibilities of outcome.
BTW. You should also be very wary of passing pointers to memory allocated on the stack of one thread as the thread argument to another. I realise it was only demo code, but it's worth a heads up.
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] |