[Mono-list] mono clr via pythonnet: invalid pointer
William Ivanski
william.ivanski at gmail.com
Tue Jan 24 19:23:56 UTC 2017
nPython.exe is just a C# tool to simulate the behavior of pure python
interpreter. It uses Python.Runtime.dll, which is also C# and contains all
logic to make the "bridge" between:
- Native calls to Python and program logic: they all are simply redirected
to pure python interpreter already installed in your system.
- Instantiations of C# objects (from C# itself or contained in an dll
referenced by your script): they are kept in "C# realm" and only translated
to a way python can understand.
I didn't compile python here, I only compiled nPython. Do you need to
compile python too? Can't you just install python on your system via apt?
Em ter, 24 de jan de 2017 às 16:49, Daniel Krause <madakr at web.de> escreveu:
> Hello William,
>
> I tried your nPython.exe, yes, it works on my raspberry.
>
> Could you explain, what you did to create this python-version? Did you
> compile it on Windows?
> And how would you add modules like numpy etc?
> I am sorry if these questions sound silly, but I have no experience with
> compiling python from scratch.
>
> Thanks a lot for your support so far
> Daniel
>
>
> 2017-01-22 22:03 GMT+01:00 Daniel Krause <madakr at web.de>:
>
> Hi,
>
> I tried to compile python 3.6 from source.
> ./configure
> make
> worked without problems.
>
> But
> make test
> failed.
> The logfile is attached.
>
> I am afraid this problem is beyond the scope of this mailing list, but
> perhaps someone has an idea anyway.
>
> Thanks
> Daniel
>
> 2017-01-22 19:38 GMT+01:00 William Ivanski <william.ivanski at gmail.com>:
>
> Hey, Daniel,
>
> Maybe it's a bug on the version of Python for .NET you compiled. Maybe if
> you try the .EXE and .DLL I compiled and sent you?
>
> Em dom, 22 de jan de 2017 às 15:10, Daniel Krause <madakr at web.de>
> escreveu:
>
> Hello,
>
> I installed the current mono-version 4.6.2.16-0xamarin1 and upgraded my
> system with `sudo -H apt-get upgrade mono-complete`.
> The examples for mono worked (I tested the console example and the winform
> example), the clr import from python still gives me errors:
>
> import clr
> *** Error in `python3.5': free(): invalid pointer: 0x76011050 ***
> Stacktrace:
>
> at <unknown> <0xffffffff>
> at (wrapper managed-to-native) Python.Runtime.Runtime.Py_Initialize ()
> <0x00033>
> at Python.Runtime.Runtime.Initialize () <0x00027>
> at Python.Runtime.PythonEngine.Initialize () <0x0007f>
> at Python.Runtime.PythonEngine.InitExt () <0x0002f>
> at (wrapper runtime-invoke) <Module>.runtime_invoke_intptr
> (object,intptr,intptr,intptr) <0x0006f>
>
> Native stacktrace:
>
>
> Debug info from gdb:
>
> [New LWP 21070]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library
> "/lib/arm-linux-gnueabihf/libthread_db.so.1".
> __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
> 46 ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or
> directory.
> Id Target Id Frame
> * 1 Thread 0x76f1c300 (LWP 21069) "python3.5" __libc_do_syscall () at
> ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
> 2 Thread 0x761b1470 (LWP 21070) "Finalizer" __libc_do_syscall () at
> ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
>
> Thread 2 (Thread 0x761b1470 (LWP 21070)):
> #0 __libc_do_syscall () at
> ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
> #1 0x76eb2834 in futex_abstimed_wait_cancelable (private=0, abstime=0x0,
> expected=1, futex_word=0x76843c78) at
> ../sysdeps/unix/sysv/linux/futex-internal.h:205
> #2 do_futex_wait (sem=sem at entry=0x76843c78, abstime=0x0) at
> sem_waitcommon.c:115
> #3 0x76eb2916 in __new_sem_wait_slow (sem=0x76843c78, abstime=0x0) at
> sem_waitcommon.c:282
> #4 0x76734cc4 in ?? () from /usr/lib/libmonoboehm-2.0.so.1
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> Thread 1 (Thread 0x76f1c300 (LWP 21069)):
> #0 __libc_do_syscall () at
> ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
> #1 0x76eb432a in __waitpid (pid=21071, stat_loc=0x7eb086e4, options=0) at
> ../sysdeps/unix/sysv/linux/waitpid.c:29
> #2 0x76695d08 in ?? () from /usr/lib/libmonoboehm-2.0.so.1
>
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> =================================================================
> 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)
>
> 2017-01-18 13:37 GMT+01:00 William Ivanski <william.ivanski at gmail.com>:
>
> Hey, Daniel,
>
> Sorry I didn't ask from which repo you installed mono on your system. I'm
> assuming you installed from Ubuntu repo, which provides mono 4.2 even on
> Ubuntu 16.10.
>
> If you want to try mono 4.6, you may be able to install it on your system
> from official mono repo:
> http://www.mono-project.com/docs/getting-started/install/linux/
>
> Please let me know if it works for you.
>
> Em qua, 18 de jan de 2017 às 10:31, Daniel Krause <madakr at web.de>
> escreveu:
>
> Hi William,
>
> it is good to hear, that Ubuntu 16.10 is working.
> Unfortunately there is no Ubuntu 16.10 for Raspberry available (or let's
> say, I did not find it, and I would be happy with the LTS-version...).
>
> Pythonnet is compiled from github as on your machine. I am using the same
> mono-version as the pythonnet project uses for its testing, but on my
> machine something is not working.
>
> You are also using a newer version of mono.
>
> Maybe there is a way to upgrade the version of mono on my system to
> version 4.6.2 to give that a test?
>
> Thanks
> Daniel
>
>
> 2017-01-18 11:56 GMT+01:00 William Ivanski <william.ivanski at gmail.com>:
>
> Hi, Andres, Daniel and others,
>
> It works, I'm using Kubuntu 16.10 and mono 4.6.2. To run:
>
> mono nPython.exe test.py
>
> I compiled Python for .NET myself from GitHub repo. You can always toss
> away the EXE and the DLL, and compile them yourself.
>
> Em qua, 18 de jan de 2017 às 03:16, Andres <knocte at gmail.com> escreveu:
>
> Daniel, and others, I advice not to consume random binaries from random
> people on the internet.
>
> On Wednesday, January 18, 2017 06:09 AM, William Ivanski wrote:
> > Please see solution
> > here:
> https://drive.google.com/file/d/0B6qR86JfcfthdDNwS2g4V2RFRmc/view?usp=sharing
> >
> > It works, I'm using Kubuntu 16.10 and mono 4.6.2. I compiled Python for
> > .NET myself from GitHub repo.
> > To run:
> >
> > mono nPython.exe test.py
> >
> > Em ter, 17 de jan de 2017 às 18:57, Daniel Krause <madakr at web.de
> > <mailto:madakr at web.de>> escreveu:
> >
> > Hello,
> >
> > I am trying to to use mono from python via pythonnet.
> >
> > My system:
> >
> > *Ubuntu*
> >
> > * Release 16.04.1 LTS (Xenial Xerus) 32-bit
> > * Kernel Linux 4.1.19-v7+ armv7l
> > * MATE 1.12.1
> >
> > *Hardware*
> >
> > * Memory: 925,8 MiB
> > * Processor: ARMv7 Processor rev 4 (v7l) × 4
> >
> > *Mono: *mono-complete (4.2.4.4-0wheezy1)
> >
> > **More information on the system and installed dependencies for
> > pythonnet can be found in this thread:
> > https://github.com/pythonnet/pythonnet/issues/327
> >
> > The following small test script fails at the first step (importing
> > the clr):
> > #!/usr/bin/env python3
> >
> > print('import clr')
> > import clr
> > print('clr imported')
> >
> > if __name__ == '__main__':
> > print('main')
> > exit(0)
> >
> > It gives the following traceback:
> > import clr
> > *** Error in `python3.5': free(): invalid pointer: 0x75b92050 ***
> > Stacktrace:
> >
> > at <unknown> <0xffffffff>
> > at (wrapper managed-to-native)
> > Python.Runtime.Runtime.Py_Initialize () <0xffffffff>
> > at Python.Runtime.Runtime.Initialize () <0x0002f>
> > at Python.Runtime.PythonEngine.Initialize () <0x00093>
> > at Python.Runtime.PythonEngine.InitExt () <0x0002f>
> > at (wrapper runtime-invoke) <Module>.runtime_invoke_intptr
> > (object,intptr,intptr,intptr) <0xffffffff>
> >
> > Native stacktrace:
> >
> >
> > Debug info from gdb:
> >
> > [New LWP 1901]
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library
> > "/lib/arm-linux-gnueabihf/libthread_db.so.1".
> > 0x76f23454 in __libc_do_syscall () from
> > /lib/arm-linux-gnueabihf/libpthread.so.0
> > Id Target Id Frame
> > * 1 Thread 0x76f8a300 (LWP 1900) "python3.5" 0x76f23454 in
> > __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0
> > 2 Thread 0x76250470 (LWP 1901) "Finalizer" 0x76f23454 in
> > __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0
> >
> > Thread 2 (Thread 0x76250470 (LWP 1901)):
> > #0 0x76f23454 in __libc_do_syscall () from
> > /lib/arm-linux-gnueabihf/libpthread.so.0
> > #1 0x76f20834 in do_futex_wait.constprop () from
> > /lib/arm-linux-gnueabihf/libpthread.so.0
> > #2 0x76f20916 in __new_sem_wait_slow.constprop.0 () from
> > /lib/arm-linux-gnueabihf/libpthread.so.0
> > #3 0x767dae84 in mono_sem_wait () from
> /usr/lib/libmonoboehm-2.0.so.1
> > #4 0x767a89a0 in ?? () from /usr/lib/libmonoboehm-2.0.so.1
> > Backtrace stopped: previous frame identical to this frame (corrupt
> > stack?)
> >
> > Thread 1 (Thread 0x76f8a300 (LWP 1900)):
> > #0 0x76f23454 in __libc_do_syscall () from
> > /lib/arm-linux-gnueabihf/libpthread.so.0
> > #1 0x76f2232a in waitpid () from
> > /lib/arm-linux-gnueabihf/libpthread.so.0
> > #2 0x767122bc in ?? () from /usr/lib/libmonoboehm-2.0.so.1
> > Backtrace stopped: previous frame identical to this frame (corrupt
> > stack?)
> >
> > =================================================================
> > 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)
> >
> > My debugging skills are very poor, anyway, I tried to use valgrind
> > to get perhaps a better idea. The output:
> > ==2813== Memcheck, a memory error detector
> > ==2813== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et
> al.
> > ==2813== Using Valgrind-3.11.0 and LibVEX; rerun with -h for
> > copyright info
> > ==2813== Command: python3.5 pythonnet_test.py
> > ==2813==
> > disInstr(arm): unhandled instruction: 0xF1010200
> > cond=15(0xF) 27:20=16(0x10) 4:4=0 3:0=0(0x0)
> > ==2813== valgrind: Unrecognised instruction at address 0x48596f4.
> > ==2813== at 0x48596F4: ??? (in
> > /usr/lib/arm-linux-gnueabihf/libarmmem.so)
> > ==2813== Your program just tried to execute an instruction that
> Valgrind
> > ==2813== did not recognise. There are two possible reasons for this.
> > ==2813== 1. Your program has a bug and erroneously jumped to a
> non-code
> > ==2813== location. If you are running Memcheck and you just saw a
> > ==2813== warning about a bad jump, it's probably your program's
> > fault.
> > ==2813== 2. The instruction is legitimate but Valgrind doesn't
> > handle it,
> > ==2813== i.e. it's Valgrind's fault. If you think this is the
> > case or
> > ==2813== you are not sure, please let us know and we'll try to
> > fix it.
> > ==2813== Either way, Valgrind will now raise a SIGILL signal which
> will
> > ==2813== probably kill your program.
> > ==2813==
> > ==2813== Process terminating with default action of signal 4 (SIGILL)
> > ==2813== Illegal opcode at address 0x48596F4
> > ==2813== at 0x48596F4: ??? (in
> > /usr/lib/arm-linux-gnueabihf/libarmmem.so)
> > ==2813==
> > ==2813== HEAP SUMMARY:
> > ==2813== in use at exit: 1,088 bytes in 10 blocks
> > ==2813== total heap usage: 62 allocs, 52 frees, 5,692 bytes
> allocated
> > ==2813==
> > ==2813== LEAK SUMMARY:
> > ==2813== definitely lost: 0 bytes in 0 blocks
> > ==2813== indirectly lost: 0 bytes in 0 blocks
> > ==2813== possibly lost: 0 bytes in 0 blocks
> > ==2813== still reachable: 1,088 bytes in 10 blocks
> > ==2813== suppressed: 0 bytes in 0 blocks
> > ==2813== Rerun with --leak-check=full to see details of leaked memory
> > ==2813==
> > ==2813== For counts of detected and suppressed errors, rerun with: -v
> > ==2813== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from
> 0)
> > Illegal instruction (core dumped)
> >
> > Both the traceback from python and the output of valgrind are beyond
> > my comprehension.
> >
> > Has anyone have an idea, what is wrong, and how to fix it?
> >
> > Thanks
> > Daniel
> > _______________________________________________
> > Mono-list maillist - Mono-list at lists.dot.net
> > <mailto:Mono-list at lists.dot.net>
> > http://lists.dot.net/mailman/listinfo/mono-list
> >
> > --
> >
> > William Ivanski - Microsoft MVP
> >
> >
> >
> > _______________________________________________
> > Mono-list maillist - Mono-list at lists.dot.net
> > http://lists.dot.net/mailman/listinfo/mono-list
> >
>
> --
William Ivanski - Microsoft MVP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dot.net/pipermail/mono-list/attachments/20170124/769e2045/attachment-0001.html>
More information about the Mono-list
mailing list