Bug 493260 - python crash (inside libselinux) while exiting with 'import socket'
python crash (inside libselinux) while exiting with 'import socket'
Status: CLOSED DUPLICATE of bug 537040
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: libselinux (Show other bugs)
5.4
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Daniel Walsh
BaseOS QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-01 02:44 EDT by Kirby Zhou
Modified: 2010-12-16 08:58 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-07 07:22:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kirby Zhou 2009-04-01 02:44:19 EDT
Description of problem:

python crash while exiting with 'import socket'.
it seems crashing in selinux module, I'm not sure whether a bug of python or selinux.

Version-Release number of selected component (if applicable):
[root@xen-727057 ~]# rpm -q python libselinux glibc kernel-xen glibc
python-2.4.3-24.el5
libselinux-1.33.4-5.1.el5
libselinux-1.33.4-5.1.el5
glibc-2.5-34
glibc-2.5-34
kernel-xen-2.6.18-128.el5
glibc-2.5-34
glibc-2.5-34

How reproducible:


Steps to Reproduce:

   python -c 'import socket'
  
Actual results:

   Segmentation fault

Expected results:

   Nothing happens

Additional info:

[root@xen-727057 ~]# gdb `which python`
GNU gdb Fedora (6.8-27.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
(gdb) r -c 'import socket'
Starting program: /usr/bin/python -c 'import socket'
[Thread debugging using libthread_db enabled]
[New Thread 0x2aaaaaac2f60 (LWP 4879)]

Program received signal SIGSEGV, Segmentation fault.
0x00000031f360f57c in fini_context_translations () at setrans_client.c:207
207                     free(prev_r2t_trans);
(gdb) bt
#0  0x00000031f360f57c in fini_context_translations () at setrans_client.c:207
#1  0x00000031f36045bf in __do_global_dtors_aux () from /lib64/libselinux.so.1
#2  0x0000000000000000 in ?? ()
(gdb)
Comment 1 Daniel Walsh 2009-04-01 14:53:08 EDT
If you turn off mcstrans does the problem go away.

service mcstrans stop

 /usr/bin/python -c 'import socket'
Comment 2 Kirby Zhou 2009-04-07 11:22:25 EDT
The problem goes away with mcstrans off, but I cannot reproduce it any more even if I turned mcstrans on again.

I cannot close the bug by myself.
Comment 3 Daniel Walsh 2009-04-08 08:59:40 EDT
Well i have no idea.  This code has been out there for a while and have not heard of any crashes.
Comment 4 Kirby Zhou 2009-09-15 12:16:35 EDT
It appers again after I upgrade from 5.3 to 5.4

]# rpm -q python libselinux glibc kernel-xen glibc
python-2.4.3-27.el5
libselinux-1.33.4-5.5.el5
libselinux-1.33.4-5.5.el5
glibc-2.5-42
glibc-2.5-42
kernel-xen-2.6.18-164.el5

]# cat btcp.py 
from socket import *

]# getsebool 
getsebool:  SELinux is disabled

]# service mcstrans stop

~]# gdb /usr/bin/python
GNU gdb Fedora (6.8-37.el5)
(gdb) r btcp.py 

Program received signal SIGSEGV, Segmentation fault.
0x0000003b5500f5cc in fini_context_translations () at setrans_client.c:207
207                     free(prev_r2t_trans);
(gdb) bt
#0  0x0000003b5500f5cc in fini_context_translations () at setrans_client.c:207
#1  0x0000003b550045df in __do_global_dtors_aux () from /lib64/libselinux.so.1
#2  0x0000000000000000 in ?? ()
(gdb) 


The core file generated is too big, even more than 11M after bzip2.
Comment 5 Paul Shaklan 2010-01-11 13:38:57 EST
Is it possible that this is related to Fedora Bug 484595?

https://bugzilla.redhat.com/show_bug.cgi?id=484595

I think it's likely that the following example produces a symptom of the same problem:

// foo.C ///////////////////////////////////////////////////////////////////
// compiled with 'g++ -g foo.C -shared -rdynamic -ldl -lselinux -o libfoo.so')

#include <iostream>

extern "C" void my_function()
{
  std::cerr << "my_function" << std::endl;
}


// test.C /////////////////////////////////////////////////////////////////
// compiled with 'g++ -g -ldl test.C'

#include <iostream>
#include <dlfcn.h>

int main()
{
  void* libHandle = dlopen("./libfoo.so", RTLD_NOW | RTLD_GLOBAL);

  if( libHandle != NULL )
  {
    typedef void (*RegisterMethodType)();
      RegisterMethodType function =
        reinterpret_cast< RegisterMethodType >(
          reinterpret_cast< int >( dlsym( libHandle, "my_function" ) ) );

    if( function != NULL )
      function();
    else
      std::cerr << "unable to call my_function" << std::endl;


    if( dlclose( libHandle ) != 0 )
      std::cerr << "dlclose error: " << dlerror() << std::endl;
    else
      std::cerr << "dlclose successful" << std::endl;
  }
  else
  {
    std::cerr << "unable to dlopen libfoo.so" << std::endl;
  }
  return 0;
}

Running the above yields a segmentation fault with the following backtrace:

GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols [...]...done.

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from ./libfoo.so...done.
Loaded symbols for ./libfoo.so
Reading symbols from /lib/libselinux.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libselinux.so.1
Reading symbols from /lib/libsepol.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libsepol.so.1
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0  0x00a7178e in ?? () from /lib/libselinux.so.1
(gdb) bt
#0  0x00a7178e in ?? () from /lib/libselinux.so.1
#1  0x00a6ced2 in ?? () from /lib/libselinux.so.1
#2  0x00a65592 in ?? () from /lib/libselinux.so.1
#3  0x00a78eec in ?? () from /lib/libselinux.so.1
#4  0x00000009 in ?? ()
#5  0xbf949e28 in ?? ()
#6  0x00a6553a in ?? () from /lib/libselinux.so.1
#7  0x00a78ff4 in ?? () from /lib/libselinux.so.1
#8  0x086eb338 in ?? ()
#9  0xbf949da8 in ?? ()
#10 0x00a724bc in _fini () from /lib/libselinux.so.1
Backtrace stopped: frame did not save the PC


Additional notes
- I'm running 'Red Hat Enterprise Linux Server release 5.3 (Tikanga)'
- I built this example using g++ 4.4.1 (the program doesn't core when built with g++ 3.4.6).
- selinux is not enabled on my server
- The example above won't core if test.c is explicitly linked to lselinux
- The example above won't core if foo.C is not linked to lselinux
- In the example above, the crash occurs within dlclose; without dlclose, the crash occurs at exit.
Comment 6 Miroslav Grepl 2010-07-02 09:29:38 EDT
Kirby,
are you still getting this issue in RHEL5.5?
Comment 9 Miroslav Grepl 2010-12-07 07:22:26 EST

*** This bug has been marked as a duplicate of bug 537040 ***

Note You need to log in before you can comment on or make changes to this bug.