[Mono-list] mono clr via pythonnet: invalid pointer

William Ivanski william.ivanski at gmail.com
Wed Jan 18 10:56:03 UTC 2017


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
> >
>
>
> _______________________________________________
> 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/20170118/63fd7e42/attachment-0001.html>


More information about the Mono-list mailing list