Re: mono clr via pythonnet: invalid pointer

A follow-up from my side:
The simplified test code was running with nPython.exe, but not with
pythonnet (some library in the ubuntu system was throwing an error...).
I tried if it was possible to run my code with nPython.exe, that failed as
I use additional libraries and drivers which could not be handled through
nPython.

I made an attempt to install a fresh Ubuntu in a VM ( so no
arm-architecture, just normal PC), went again through all the steps of
installing mono and pythonnet, but it still did not work...

At that point I simply gave up wasting my time chasing errors I do not
understand.
A tiny windows PC is doing now its work, up and running smoothly in less
than one evening... The price (with windows installed) is appr. 7 times
higher than an raspberry, but at least I have now a working solution :-/.

Maybe it safes someone else some time (though not money...).

Daniel

2017-01-24 20:23 GMT+01:00 William Ivanski <[email protected]>:

> 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 <[email protected]>
> 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 <[email protected]>:
>>
>> 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 <[email protected]>:
>>
>> 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 <[email protected]>
>> 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@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 <[email protected]>:
>>
>> 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 <[email protected]>
>> 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 <[email protected]>:
>>
>> 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 <[email protected]> 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 <[email protected]
>> > <mailto:[email protected]>> 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  -  [email protected]
>> >     <mailto:[email protected]>
>> >     http://lists.dot.net/mailman/listinfo/mono-list
>> >
>> > --
>> >
>> > William Ivanski - Microsoft MVP
>> >
>> >
>> >
>> > _______________________________________________
>> > Mono-list maillist  -  [email protected]
>> > http://lists.dot.net/mailman/listinfo/mono-list
>> >
>>
>> --
>
> William Ivanski - Microsoft MVP
>

_______________________________________________
Mono-list maillist  -  [email protected]
http://lists.dot.net/mailman/listinfo/mono-list