[Mono-list] mono clr via pythonnet: invalid pointer

[Daniel Krause]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dot.net/pipermail/mono-list/attachments/20170117/1bcd71ad/attachment.html>