[vtkusers] vtkpython:Linux SMP:SIGSEGV upon import vtk

Fri Feb 28 10:57:03 EST 2003

Hi Prabhu,

Prabhu Ramachandran wrote:
>  1. Was VTK built on this same machine or was it built elsewhere and
>  used on this machine?

Built on uni-processor, used on SMP.

>  2. I used to believe that the gcc, glibc and all should kind of be in
>  sync.  So could this be because you are using gcc-3.04 on RH 6.1 with
>  its older glibc compiled on an older gcc version?  Could there be a
>  problem with the linker?  I don't know enough about this to say
>  anything definitive but maybe something worth thinking about?
>  Perhaps you can try building it with the default RH 6.1 compiler?  Or
>  better still upgrade the machine.

It does seem to be a glibc thing.  I did try rebuilding all on a newer,
but still uni-processort Red Hat 7.1 (Seawolf) 2.4.18-24.7.x using gcc
3.2.2.  When I run my application on the build client, the
crash-on-vtk-write problem I had with python goes away.  But when I try
to run it on the remote client running SuSE 7.1 2.2.18-SMP, python
starts, but aborts SIGABRT with the _dlerror_run I previously got with
vtkpython: 

#23 0x40038790 in _dlerror_run () from /lib/libdl.so.2
#24 0x40038393 in dlopen@@GLIBC_2.1 () from /lib/libdl.so.2
#25 0x080733de in _PyImport_GetDynLoadFunc (
    fqname=0xbfff7ff4 "libvtkCommonPython", shortname=0x0, 
    pathname=0xbfff7b60 "/home/donna/SUREfit/lib/libvtkCommonPython.so", 
    fp=0x825f1d0) at Python/dynload_shlib.c:90

Now vtkpython aborts on startup SIGABRT with:

Program received signal SIGABRT, Aborted.
[Switching to Thread 1024 (LWP 9638)]
0x41f60bc1 in __kill () at __kill:-1
-1	__kill: No such file or directory.
	in __kill
(gdb) where
#0  0x41f60bc1 in __kill () at __kill:-1
#1  0x4002a7ac in pthread_kill () from /lib/libpthread.so.0
#2  0x4002ac96 in raise () from /lib/libpthread.so.0
#3  0x41f61fe1 in abort () from /lib/libc.so.6
#4  0x41ebd467 in __cxxabiv1::__terminate(void (*)()) (
    handler=0x8051cc8 <abort>)
    at
/usr/local/src/gcc3.2.2/srcdir/libstdc++-v3/libsupc++/eh_terminate.cc:47
#5  0x41ebd4b4 in std::terminate() ()
    at
/usr/local/src/gcc3.2.2/srcdir/libstdc++-v3/libsupc++/eh_terminate.cc:57
#6  0x41ebd4d7 in __cxxabiv1::__unexpected(void (*)()) (
    handler=0x41ebd490 <std::terminate()>)
    at
/usr/local/src/gcc3.2.2/srcdir/libstdc++-v3/libsupc++/eh_terminate.cc:63
#7  0x41ebd365 in __cxa_call_unexpected (exc_obj_in=0x80d6008)
    at
/usr/local/src/gcc3.2.2/srcdir/libstdc++-v3/libsupc++/eh_personality.cc:456
#8  0x41eaf69a in locale (this=0x0) at localefwd.h:298
#9  0x41ec76d7 in basic_filebuf (this=0x41f263c0) at streambuf:350
#10 0x41ec6ca2 in stdio_filebuf (this=0x41f263c0, __f=0x0, __mode=16,
__size=0)
    at ext/stdio_filebuf.h:146
#11 0x41eaea06 in std::ios_base::Init::_S_ios_create(bool) (__sync=60)
    at new:89
#12 0x41eaef75 in Init (this=0x41f26c80)
    at /usr/local/src/gcc3.2.2/srcdir/libstdc++-v3/src/ios.cc:218
#13 0x41eae797 in __static_initialization_and_destruction_0 (
    __initialize_p=1106286176, __priority=65535) at iostream:63
#14 0x41eae7ba in
_GLOBAL__I__ZThn8_NSt14basic_iostreamIwSt11char_traitsIwEED0Ev_usr_local_src_gcc3.2.2_srcdir_libstdc___v3_src_io_inst.ccUJXkhb
()
    at locale_facets.h:107
#15 0x41eac2d5 in __do_global_ctors_aux ()
   from /home/donna/SUREfit/lib/libstdc++.so.5
#16 0x41ea955e in _init () from /home/donna/SUREfit/lib/libstdc++.so.5
#17 0x4000d60f in _dl_init () from /lib/ld-linux.so.2
(gdb) quit

I don't think the SuSE system likes my libstdc++ that I copied from my
build client.

>  3. Also try and see if a Python recompile from source on this machine
>  helps when you use the newer compiler.

Logistical constraints kept me from trying this sooner, but it's time to
bite the bullet.

>  4. vtkpython remembers where the original libraries were installed
>  and imports those libraries.  Maybe you have a few versions of the
>  VTK libraries on the system.  Can you make sure that there is only
>  one set of libraries on your system?

Don't think so.  Both my ldd and stack trace output tell me I'm linking
to the right libraries.  Vtk was built right after python, using the
same compiler, etc.  (For gory details, see
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/surefit/SureFitSrc/BuildSureFit).

Since I have another user running uni-processor SuSE with no problems, I
suspected SMP/threads were somehow implicated, and this link from a
yahoo search intrigued me:

http://www.phpbuilder.com/mail/php-developer-list/2000102/1081.php

This is a glibc-2.1.x bug triggered by loading a dynamic library linked
against pthreads into a binary that is not linked against pthreads. 

I knew python, vtkpython, and vtk were all linked to pthreads, but I
tried rebuilding all without (e.g., configured python --with-threads=no
and CMAKE_USE_PTHREADS:BOOL=0).  But python still can't load
libvtkCommon.so.

Thanks for your ideas on this.  They are appreciated.

Donna