Import clr fails on Linux64/Mono #119

rihardsk · 2016-01-21T13:09:35Z

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...

The text was updated successfully, but these errors were encountered:

den-run-ai · 2016-01-22T15:09:35Z

UCS2 or UCS4?

tonyroberts · 2016-01-22T16:27:28Z

Try the develop branch.

rihardsk · 2016-01-25T14:09:55Z

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

tonyroberts · 2016-01-25T16:15:36Z

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.

rihardsk · 2016-01-27T16:00:11Z

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.

oysols · 2016-02-10T00:33:17Z

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

mikofski · 2016-03-15T01:14:18Z

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

Alvarz · 2016-04-06T15:37:24Z

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

den-run-ai · 2016-04-28T04:54:09Z

@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 · 2016-04-28T11:16:11Z

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 notifications@github.com
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)

maksimlinio · 2016-08-18T21:05:13Z

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]
`

den-run-ai · 2016-08-19T02:06:28Z

@maksimlinio use mono 4.2.4.4 and see discussion here:

#241

den-run-ai · 2016-09-06T03:45:24Z

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

#119

den-run-ai · 2016-12-04T07:45:54Z

@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

* Update setup.py #119 * Update setup.py * Update setup.py * Update setup.py * Update .travis.yml no more python 2.6 - missing subprocess.check_output() * Small cleanup.

den-run-ai · 2016-12-07T17:00:08Z

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

AlexCatarino · 2016-12-13T19:56:26Z

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...

den-run-ai · 2017-03-20T05:25:56Z

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

#245 (comment)

This was referenced Mar 15, 2016

Segfault on import of clr under Arch Linux64/Mono #110

Closed

on Linux with Mono FileStream(String, FileMode) says no constructor matches #187

Closed

den-run-ai mentioned this issue Apr 28, 2016

setup.py fails on Ubuntu14.04 / 64Bit #209

Closed

den-run-ai added bug question and removed bug labels Sep 6, 2016

den-run-ai added release-blocking and removed question labels Dec 4, 2016

den-run-ai pushed a commit that referenced this issue Dec 4, 2016

Update setup.py

64dba41

#119

den-run-ai mentioned this issue Dec 4, 2016

Work around a broken shared detection on some platforms #300

Merged

den-run-ai closed this as completed Dec 7, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Import clr fails on Linux64/Mono #119

Import clr fails on Linux64/Mono #119

rihardsk commented Jan 21, 2016

den-run-ai commented Jan 22, 2016

tonyroberts commented Jan 22, 2016

rihardsk commented Jan 25, 2016

tonyroberts commented Jan 25, 2016

rihardsk commented Jan 27, 2016

oysols commented Feb 10, 2016

mikofski commented Mar 15, 2016

Alvarz commented Apr 6, 2016

den-run-ai commented Apr 28, 2016

Alvarz commented Apr 28, 2016

maksimlinio commented Aug 18, 2016 •

edited

Loading

den-run-ai commented Aug 19, 2016

den-run-ai commented Sep 6, 2016

den-run-ai commented Dec 4, 2016

den-run-ai commented Dec 7, 2016

AlexCatarino commented Dec 13, 2016

den-run-ai commented Mar 20, 2017 •

edited

Loading

Import clr fails on Linux64/Mono #119

Import clr fails on Linux64/Mono #119

Comments

rihardsk commented Jan 21, 2016

den-run-ai commented Jan 22, 2016

tonyroberts commented Jan 22, 2016

rihardsk commented Jan 25, 2016

tonyroberts commented Jan 25, 2016

rihardsk commented Jan 27, 2016

oysols commented Feb 10, 2016

mikofski commented Mar 15, 2016

Alvarz commented Apr 6, 2016

den-run-ai commented Apr 28, 2016

Alvarz commented Apr 28, 2016

maksimlinio commented Aug 18, 2016 • edited Loading

den-run-ai commented Aug 19, 2016

den-run-ai commented Sep 6, 2016

den-run-ai commented Dec 4, 2016

den-run-ai commented Dec 7, 2016

AlexCatarino commented Dec 13, 2016

den-run-ai commented Mar 20, 2017 • edited Loading

maksimlinio commented Aug 18, 2016 •

edited

Loading

den-run-ai commented Mar 20, 2017 •

edited

Loading