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

Andres knocte at gmail.com
Wed Jan 18 05:16:02 UTC 2017


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
>




More information about the Mono-list mailing list