prabakar.bhatt, first of all, I don't understand what's the thinking processes of anyone asking for help with so little information - as if someone sends an SOS with only Latitude and needs to be asked a second time to send their Longitude as well. Perhaps you want to test us for the priesthood at Delphi? May be so, but I find it very irritating to beg the person with a problem for more information to solve his problem. That said, and after reading your response to perlfan's and dave_the_m's questions ...
See Maintaining multiple interpreter instances
It is not clear to me if what's crashing is 3rd-party code (marto mentioned HP's), in which case I will assume that code is correct and the problem may be with how your perl libraries were compiled (and btw make sure it's the correct libraries it is linking to! Re: site perl vs perlbrew perl etc.etc.). This could be the problem especially if with the same 3rd-party code, previously you got no crash.
On the other hand, if what's crashing is your own C++ program which embeds a perl interpreter, then you must both check above point AND ALSO how you spawn the thread, embed and clean-up afterwards. Or if you attempt to use other thread's interpreters. Or if one perl interpreter unsuspectfully cleans up other interpreter's space. That can be tricky to get right even without threads. So again read the documentation I mentioned above which states how you should compile the perl libraries in the first place.
Additionally and for both cases above: since what's crashing is strchr(), can this be an issue of unicode strings and incorrect length? That means, the Perl content, i.e. script to your embeded interpreters may be to blame. So, perhaps try it with minimal Perl scripts and without unicode if any at all which btw can be user-supplied (unicode) input.
I don't know if you are in a position to run all these under a debugger. But if you are then checking what are the args to the crashing strchr() will give you a good hint.
bw, bliako
| 