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