Import clr fails on Linux64/Mono

Running python -c 'import clr' 2>&1 gives

*** Error in `python': double free or corruption (out): 0x00007ff2a2b41180 ***
Stacktrace:

  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) Python.Runtime.Runtime.Py_Initialize () <0xffffffff>
  at Python.Runtime.Runtime.Initialize () <0x0003f>
  at Python.Runtime.PythonEngine.Initialize () <0x00047>
  at Python.Runtime.PythonEngine.InitExt () <0x0000f>
  at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:

        /usr/lib/libmonoboehm-2.0.so.1(+0xcce3a) [0x7ff2a417de3a]
        /lib/x86_64-linux-gnu/libpthread.so.0(+0x10d10) [0x7ff2a56ffd10]
        /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37) [0x7ff2a535a267]
        /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a) [0x7ff2a535beca]
        /lib/x86_64-linux-gnu/libc.so.6(+0x78c53) [0x7ff2a539dc53]
        /lib/x86_64-linux-gnu/libc.so.6(+0x80c69) [0x7ff2a53a5c69]
        /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c) [0x7ff2a53a989c]
        /usr/lib/x86_64-linux-gnu/libpython2.7.so(PyString_InternInPlace+0x90) [0x7ff2a2c65ae0]
        /usr/lib/x86_64-linux-gnu/libpython2.7.so(PyString_InternFromString+0x2a) [0x7ff2a2c65b6a]
        /usr/lib/x86_64-linux-gnu/libpython2.7.so(PyType_Ready+0x1b25) [0x7ff2a2c6b6f5]
        /usr/lib/x86_64-linux-gnu/libpython2.7.so(_Py_ReadyTypes+0xb0) [0x7ff2a2c59360]
        /usr/lib/x86_64-linux-gnu/libpython2.7.so(Py_InitializeEx+0x76) [0x7ff2a2ce2106]
        [0x4181c411]

Debug info from gdb:


=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

Aborted (core dumped)

I'm on a clean Ubuntu Wily64 system with some deps installed ontop:

mono-complete
libperl-dev
libgtk2.0-dev
python-dev

Pythonnet seems to install fine. Installing from develop branch gives

Unpacking /home/vagrant/src/pythonnet
  Running setup.py (path:/tmp/pip-ndk1WW-build/setup.py) egg_info for package from file:///home/vagrant/src/pythonnet

Installing collected packages: pythonnet
  Running setup.py install for pythonnet
    All packages listed in packages.config are already installed.
    XBuild Engine Version 12.0
    Mono, Version 3.2.8.0
    Copyright (C) 2005-2013 Various Mono authors
    /tmp/pip-ndk1WW-build/pythonnet.sln:  warning : The project configuration for project 'clrmodule' corresponding to the solution configuration 'ReleaseMono|x64' was not found.
    XBuild Engine Version 12.0
    Mono, Version 3.2.8.0
    Copyright (C) 2005-2013 Various Mono authors
                Configuration: ReleaseMono Platform: x64
    /tmp/pip-ndk1WW-build/pythonnet.sln:  warning : The project configuration for project 'clrmodule' corresponding to the solution configuration 'ReleaseMono|x64' was not found.
        Configuration: ReleaseMono Platform: x64
    Configuration: ReleaseMono Platform: x64
    Configuration: Release Platform: x64
    assemblyinfo.cs(24,49): warning CS0618: `System.Security.Permissions.SecurityAction.RequestMinimum' is obsolete: `This requests should not be used'
    pythonconsole.cs(24,24): warning CS0219: The variable `a' is assigned but its value is never used
    building 'clr' extension
    x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/usr/include/python2.7 -c src/monoclr/pynetinit.c -o build/temp.linux-x86_64-2.7/src/monoclr/pynetinit.o -D_REENTRANT -I/usr/lib/pkgconfig/../../include/mono-2.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
    src/monoclr/pynetinit.c: In function ‘main_thread_handler’:
    src/monoclr/pynetinit.c:100:17: warning: variable ‘init_result’ set but not used [-Wunused-but-set-variable]
         MonoObject *init_result;
                     ^
    x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/usr/include/python2.7 -c src/monoclr/clrmod.c -o build/temp.linux-x86_64-2.7/src/monoclr/clrmod.o -D_REENTRANT -I/usr/lib/pkgconfig/../../include/mono-2.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
    src/monoclr/clrmod.c:42:18: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
     static PyObject *_initclr() {
                      ^
    x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wl,-Bsymbolic-functions -Wl,-z,relro -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security build/temp.linux-x86_64-2.7/src/monoclr/pynetinit.o build/temp.linux-x86_64-2.7/src/monoclr/clrmod.o -o build/lib.linux-x86_64-2.7/clr.so -L/usr/lib/pkgconfig/../../lib -lmono-2.0 -lm -lrt -ldl -lpthread -lglib-2.0

Successfully installed pythonnet
Cleaning up...

UCS2 or UCS4?

Try the develop branch.

@tonyroberts

@denfromufa UCS4
@tonyroberts i tried both the develop and the master branch

You could take a look at the travis CI build (which is also Ubuntu)
https://travis-ci.org/pythonnet/pythonnet/builds/101033785

One thing it could be is a problem with the version of Python you're using. There used to be issues depending on whether the python exe statically or dynamically linked the python shared object, but that (I thought) had been fixed in 9b2d6f2.

Maybe the Py_ENABLE_SHARED config var isn't set correctly in your build of Python. You could try hacking setup.py (just grep for Py_ENABLED_SHARED) and build it with and without PYTHON_WITHOUT_ENABLE_SHARED defined.

Setting defines.append("PYTHON_WITHOUT_ENABLE_SHARED") solves the issue.

I checked that ldd which python`` gives

        linux-vdso.so.1 =>  (0x00007ffcb2c44000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0462048000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0461c7e000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0461a79000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f0461876000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f046165c000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0461353000)
        /lib64/ld-linux-x86-64.so.2 (0x0000559ac5ba9000)

So it seems that the get_config_var("Py_ENABLE_SHARED") check mistakenly sets enable_shared to True.

I experience the same problem.
Setting defines.append("PYTHON_WITHOUT_ENABLE_SHARED") in setup.py solves the issue for me as well.

works for me too in develop branch on Ubuntu-14.04LTS

$ git clone https://github.com/pythonnet/pythonnet
$ cd pythonnet
$ nano setup.py # add "PYTHON_WITHOUT_ENABLE_SHARED" to setup.py:141
$ python setup.py install --user
$ python
>>> import clr

yay, works!

master branch in virtualenv did not work even with patch. :frown: but not sure about develop in virtualenv or master with --user

@mikofski

I'm still having this error on fedora 23 even after i did the steps given by @mikofski

Mono, Version 4.0.5.0
Python 2.7

@Alvarz

@Alvarz is your python 2.7 and mono provided with fedora or installed/built from elsewhere? I'm downloading fedora 23 iso image to test your problem.

@Alvarz

Thanks for your answer, both was the provided by fedora but un any case our
team decided to Run a window mschine with .net to avoid issues.

Again thanks

El jue 28/04/2016, 12:24 a.m., denfromufa [email protected]
escribió:

@Alvarz https://github.com/Alvarz is your python 2.7 and mono provided
with fedora or installed/built from elsewhere? I'm downloading fedora 23
iso image to test your problem.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#119 (comment)

@mikofski

I am still having this error

Linux Mint 17.2, Python 2.7, Mono 4.4.2

Tried recipe of @mikofski , didn't help:

`

import clr
Error: No managed allocator, but we need one for AOT.
Are you using non-standard GC options?

Stacktrace:

at <0xffffffff>
at System.Collections.Hashtable..ctor (int,single) <0x0020d>
at System.Collections.Hashtable..ctor () <0x00022>
at Python.Runtime.DelegateManager..ctor () <0x00180>
at Python.Runtime.PythonEngine.Initialize () <0x0006f>
at Python.Runtime.PythonEngine.InitExt () <0x0001b>
at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) <0x00062>

Native stacktrace:

/usr/lib/libmonosgen-2.0.so.1(+0xdac0d) [0x7f39170c6c0d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340) [0x7f3918f3a340]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39) [0x7f3918b9bcc9]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x7f3918b9f0d8]
/usr/lib/libmonosgen-2.0.so.1(+0x26c1e9) [0x7f39172581e9]
/usr/lib/libmonosgen-2.0.so.1(+0x26c3f7) [0x7f39172583f7]
/usr/lib/libmonosgen-2.0.so.1(+0x26c4a2) [0x7f39172584a2]
/usr/lib/libmonosgen-2.0.so.1(+0xc6170) [0x7f39170b2170]
/usr/lib/libmonosgen-2.0.so.1(+0xc91f4) [0x7f39170b51f4]
/usr/lib/libmonosgen-2.0.so.1(+0xcfefb) [0x7f39170bbefb]
/usr/lib/libmonosgen-2.0.so.1(+0xdccdd) [0x7f39170c8cdd]
[0x41a41c15]
`

@maksimlinio

@maksimlinio use mono 4.2.4.4 and see discussion here:

#241

FYI, today I found out that Py_ENABLE_SHARED set incorrectly is a bug in Ubuntu/Debian linux distros, that was discussed here:
https://bitbucket.org/anthony_tuininga/cx_freeze/issues/32/cant-compile-cx_freeze-in-ubuntu-1304

Here is a patch that can be applied to setup.py to workaround this bug in Ubuntu/Debian packages for CPython:

https://bitbucket.org/anthony_tuininga/cx_freeze/commits/6e933509e4528f24919708eee1a68683f8aa029b

Update setup.py

@tonyroberts

@tonyroberts @vmuriart @filmor I would like to resolve this issue before doing a release. This is breaking "import clr" on Ubuntu/Mint, Fedora.

In cx_freeze the check for PYTHON_ENABLE_SHARED is completely disabled now, maybe we should do the same?

I will try to get this tested now:

#300

Work around a broken shared detection on some platforms (#300)

@rihardsk

@rihardsk @maksimlinio @Alvarz @mikofski @oysols this is now fixed in the master branch, by inspecting the output of ldd for libpython.

After this fix, when you try to run nPython: mono nPython.exe, does it run?
In #303, I wrote what happens:

Unhandled Exception:
System.EntryPointNotFoundException: Py_IsInitialized
  at (wrapper managed-to-native) Python.Runtime.Runtime:Py_IsInitialized ()
  at Python.Runtime.Runtime.Initialize () [0x0000d] in <3b52ecce105142dc9f5c47b1d8f64b0e>:0
  at Python.Runtime.PythonEngine.Initialize () [0x00014] in <3b52ecce105142dc9f5c47b1d8f64b0e>:0
  at Python.Runtime.Py.GIL () [0x0000a] in <3b52ecce105142dc9f5c47b1d8f64b0e>:0
  at Test.Test.Main (System.String[] args) [0x00000] in <d894aae141fa4a98b826174854b8bf77>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.EntryPointNotFoundException: Py_IsInitialized
  at (wrapper managed-to-native) Python.Runtime.Runtime:Py_IsInitialized ()
  at Python.Runtime.Runtime.Initialize () [0x0000d] in <3b52ecce105142dc9f5c47b1d8f64b0e>:0
  at Python.Runtime.PythonEngine.Initialize () [0x00014] in <3b52ecce105142dc9f5c47b1d8f64b0e>:0
  at Python.Runtime.Py.GIL () [0x0000a] in <3b52ecce105142dc9f5c47b1d8f64b0e>:0
  at Test.Test.Main (System.String[] args) [0x00000] in <d894aae141fa4a98b826174854b8bf77>:0

libpython is not linked dynamically with my python installation, thus setup.py compiled with the PYTHON_WITHOUT_ENABLE_SHARED flag.

If I remove this flag, I can execute nPython, but cannot import clr...

@AlexCatarino

@AlexCatarino like discussed in this issue both embedding and extending are now resolved by @vmuriart:

#245 (comment)

Navigation Menu

Repository navigation

Import clr fails on Linux64/Mono #119

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Import clr fails on Linux64/Mono #119

Description

Activity

den-run-ai commented on Jan 22, 2016

tonyroberts commented on Jan 22, 2016

rihardsk commented on Jan 25, 2016

tonyroberts commented on Jan 25, 2016

rihardsk commented on Jan 27, 2016

oysols commented on Feb 10, 2016

mikofski commented on Mar 15, 2016

Alvarz commented on Apr 6, 2016

den-run-ai commented on Apr 28, 2016

Alvarz commented on Apr 28, 2016

maksimlinio commented on Aug 18, 2016

den-run-ai commented on Aug 19, 2016

den-run-ai commented on Sep 6, 2016

den-run-ai commented on Dec 4, 2016

den-run-ai commented on Dec 7, 2016

AlexCatarino commented on Dec 13, 2016

den-run-ai commented on Mar 20, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions