[Mono-list] mono clr via pythonnet: invalid pointer
Daniel Krause
madakr at web.de
Sun Jan 22 17:10:12 UTC 2017
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 at 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.ivanski at 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 <madakr at 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.ivanski at 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 <knocte at 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 <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
>> >
>>
>>
>> _______________________________________________
>> Mono-list maillist - 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
>>
>>
>> --
>
> William Ivanski - Microsoft MVP
>
2017-01-22 18:07 GMT+01:00 Daniel Krause <madakr at 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 at 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.ivanski at 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 <madakr at 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.ivanski at 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 <knocte at 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 <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
>>> >
>>>
>>>
>>> _______________________________________________
>>> Mono-list maillist - 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
>>>
>>>
>>> --
>>
>> William Ivanski - Microsoft MVP
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dot.net/pipermail/mono-list/attachments/20170122/d00265c4/attachment-0001.html>
More information about the Mono-list
mailing list