[Boost-users] [regex] Segmentation fault on regex_search only on CentOS

242 views
Skip to first unread message

Alessandro Candini

unread,
Jul 13, 2011, 4:59:13 AM7/13/11
to boost...@lists.boost.org
I have compiled the same C++ source on two machines:

1 - Ubuntu 11.04, 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:07:17
UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
2 - CentOS release 5.3, 2.6.18-128.1.14.el5 #1 SMP Wed Jun 17 06:40:54
EDT 2009 i686 i686 i386 GNU/Linux

On Ubuntu I have g++-4.5.2, on CentOs g++-4.4.4 and on both I have
boost-1.42.0.

My source compiles perfectly on both machines, but on the CentOS one I
get a Segmentetion Fault during the execution.

Using some prints, I found out where it happens:
...
boost::regex grepGPP("Monthly Ecosystem GPP", boost::regex::egrep);
cerr << "DEBUG BEFORE!" << endl;
boost::regex_search (currGPP, grepGPP)
cerr << "DEBUG AFTER!" << endl;
...

The segmentation fault comes during the execution of regex_search,
beacause "DEBUG AFTER" is not printed.

Any ideas on how to solve this problem?

Thanks in advance.

--
Alessandro Candini

MEEO S.r.l.
Via Saragat 9
I-44122 Ferrara, Italy
Tel: +39 0532 1861501
Fax: +39 0532 1861637
http://www.meeo.it

========================================
"ATTENZIONE:le informazioni contenute in questo messaggio sono
da considerarsi confidenziali ed il loro utilizzo è riservato unicamente
al destinatario sopra indicato. Chi dovesse ricevere questo messaggio
per errore è tenuto ad informare il mittente ed a rimuoverlo
definitivamente da ogni supporto elettronico o cartaceo."

"WARNING:This message contains confidential and/or proprietary
information which may be subject to privilege or immunity and which
is intended for use of its addressee only. Should you receive this
message in error, you are kindly requested to inform the sender and
to definitively remove it from any paper or electronic format."

_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

John Maddock

unread,
Jul 13, 2011, 7:23:17 AM7/13/11
to boost...@lists.boost.org
>Any ideas on how to solve this problem?

Can you run under GDB and see where the fault occurs?

John.

narinde...@uk.bnpparibas.com

unread,
Jul 13, 2011, 7:40:42 AM7/13/11
to boost...@lists.boost.org
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...@virgin.net
Sent by: boost-use...@lists.boost.org
07/13/2011 12:23 PM
Please respond to
boost...@lists.boost.org


To
boost...@lists.boost.org
cc

Subject
Re: [Boost-users] [regex] Segmentation fault on regex_search only onCentOS

___________________________________________________________
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-845C5H for additional disclosures.

Narinder Claire

unread,
Jul 14, 2011, 6:53:45 PM7/14/11
to boost...@lists.boost.org
Hi

I'll illustrate the problem I have seen in the past with an example.
It may or may not be directly or indirectly linked with the seg fault
issue you are seeing. Although mine is not a seg fault, it does
demonstrate very different behaviour between gcc on Centos (4.1.2)
and gcc on Ubuntu (4.5.2)

Consider the following 3 source files:

main.cpp ->
----------------------------------
#include<iostream>
#include"my_exception.h"

using namespace std;

void foo();
int main()
{
       try
       {
               foo();
       }
       catch(const my_exception &err)
       {
               cout << err.what();
       }
       //catch(const exception &err)
       //{
               //cout << "OOPs unknown error ";
       //}

       cout <<"\n";
}
----------------------------------

dll.cpp ->
----------------------------------
#include"my_exception.h"

void  __attribute__ ((visibility("default"))) foo()
{
  throw my_exception();
}
----------------------------------


my_exception.h ->
----------------------------------
#include<exception>

class  my_exception: public std::exception
{
public:
       virtual const char* what() const throw()
       {
               return "my_exception";
       }
       my_exception()throw(){}
       virtual ~my_exception()throw(){}
};
----------------------------------


and the following makefile

makefile ->
----------------------------------
CXX=g++
all:
       $(CXX) dll.cpp   -fvisibility=hidden  -fPIC -shared -o libdll.so
       $(CXX) main.cpp   -fPIC -L./ -ldll   -o main
clean:
       rm -fr lib*.so main

----------------------------------


Compiled on Centos 5.6 with gcc with the following specs:
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi --disable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-50)


The output is :
terminate called after throwing an instance of 'my_exception'
 what():  my_exception
Aborted

However compiled  with gcc on Ubuntu 11.04 with specs:
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.5.2-8ubuntu4'
--with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.5
--libdir=/usr/lib/x86_64-linux-gnu --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-gold
--enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc
--disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)


The output is :
my_exception


If I execute the Ubuntu compiled binary on Centos I still get the same
'Aborted' output.
If I execute the Centos compiled binary on Ubuntu I get the expected
output of the string 'my_exception'
This suggests that the 'difference' is not coming from the compiler
but from the runtime.


As stated before this may not be related to your seg fault issue but
the authors of regex could most likely tell straight away.


Best Wishes
N

Viatchesla...@h-d-gmbh.de

unread,
Jul 15, 2011, 3:10:54 AM7/15/11
to boost...@lists.boost.org

Take a look to
http://gcc.gnu.org/wiki/Visibility
chapter "How to use the new C++ visibility support" and then the section
"Problems with C++ exceptions".

Reply all
Reply to author
Forward
0 new messages