Re: mono clr via pythonnet: invalid pointer
Daniel Krause <[email protected]> Tue, 24 Jan 2017 19:49:45 +0100
| Newsgroups | gmane.comp.gnome.mono.general |
|---|---|
| Message-ID | <CAMiLiKimG4ObLWfeyy_bW6CQv0-Ved1dEC7Jkh_ZW9yk5nANDg@mail.gmail.com> |
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/libt >>> hread_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 >>> > >>> >>> >>> _______________________________________________ >>> 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 >>> >>> >>> -- >>> >>> William Ivanski - Microsoft MVP >>> >>> >>> 2017-01-22 18:07 GMT+01:00 Daniel Krause <[email protected]>: >>> >>> 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/libt >>> hread_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