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 <william.ivan...@gmail.com>: > 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 <mad...@web.de> > 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 <william.ivan...@gmail.com>: >> >> 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 <kno...@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 <mad...@web.de >> > <mailto:mad...@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@lists.dot.net >> > <mailto:Mono-list@lists.dot.net> >> > http://lists.dot.net/mailman/listinfo/mono-list >> > >> > -- >> > >> > William Ivanski - Microsoft MVP >> > >> > >> > >> > _______________________________________________ >> > Mono-list maillist - Mono-list@lists.dot.net >> > http://lists.dot.net/mailman/listinfo/mono-list >> > >> >> >> _______________________________________________ >> Mono-list maillist - Mono-list@lists.dot.net >> http://lists.dot.net/mailman/listinfo/mono-list >> >> -- >> >> William Ivanski - Microsoft MVP >> >> _______________________________________________ >> Mono-list maillist - Mono-list@lists.dot.net >> http://lists.dot.net/mailman/listinfo/mono-list >> >> >> -- > > William Ivanski - Microsoft MVP > 2017-01-22 18:07 GMT+01:00 Daniel Krause <mad...@web.de>: > 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 <william.ivan...@gmail.com>: > >> 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 <mad...@web.de> >> 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 <william.ivan...@gmail.com>: >>> >>> 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 <kno...@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 <mad...@web.de >>> > <mailto:mad...@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@lists.dot.net >>> > <mailto:Mono-list@lists.dot.net> >>> > http://lists.dot.net/mailman/listinfo/mono-list >>> > >>> > -- >>> > >>> > William Ivanski - Microsoft MVP >>> > >>> > >>> > >>> > _______________________________________________ >>> > Mono-list maillist - Mono-list@lists.dot.net >>> > http://lists.dot.net/mailman/listinfo/mono-list >>> > >>> >>> >>> _______________________________________________ >>> Mono-list maillist - Mono-list@lists.dot.net >>> http://lists.dot.net/mailman/listinfo/mono-list >>> >>> -- >>> >>> William Ivanski - Microsoft MVP >>> >>> _______________________________________________ >>> Mono-list maillist - Mono-list@lists.dot.net >>> http://lists.dot.net/mailman/listinfo/mono-list >>> >>> >>> -- >> >> William Ivanski - Microsoft MVP >> > >
_______________________________________________ Mono-list maillist - Mono-list@lists.dot.net http://lists.dot.net/mailman/listinfo/mono-list