
It's worth checking in case you are throwing exceptions accross shared library boundaries. I had a similar problem with GCC. Everything worked fine under gcc 4.5.2 (ubuntu) but not under the version of gcc that is default in CentoOS. I discovered that it was an exception being thrown in a shared library ( and defined in the shared llibrary) that I was trying to catch in my executable. I reolved it by moving all my exception definitions into a seperate shared library and linking it to all my other units including the main executable. So to clarify, if all your execeptions are defined & implemented in a header file that you are including seperately in your shared library and your executable, but you are throwing and catching acrross the boundary you may see this problem. You need to compile the exception implementations into a shared library of their own and link it in to whereever you may thorw or catch them. Regards N Internet boost.regex@virgin.net Sent by: boost-users-bounces@lists.boost.org 07/13/2011 12:23 PM Please respond to boost-users@lists.boost.org To boost-users@lists.boost.org cc Subject Re: [Boost-users] [regex] Segmentation fault on regex_search only onCentOS
Any ideas on how to solve this problem?
Can you run under GDB and see where the fault occurs? John. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users ___________________________________________________________ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is prohibited. Please refer to http://www.bnpparibas.co.uk/en/information/legal_information.asp?Code=ECAS-8... for additional disclosures.