Bug 17217 - SIGSEGV on a ARMv6 hard float
Summary: SIGSEGV on a ARMv6 hard float
Status: RESOLVED NORESPONSE
Alias: None
Product: Runtime
Classification: Mono
Component: General ()
Version: 3.2.x
Hardware: Other Other
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2014-01-14 03:44 UTC by Jiri {x2} Cincura
Modified: 2016-04-21 03:21 UTC (History)
5 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED NORESPONSE

Description Jiri {x2} Cincura 2014-01-14 03:44:45 UTC
I'm trying to run application on a Raspberry Pi (ARMv6) on a Raspbian (hard float). The application crashes (not in a deterministic way) with:

Stacktrace:

  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) System.Buffer.BlockCopyInternal (System.Array,int,System.Array,int,int) <0xffffffff>
  at System.IO.FileStream.ReadSegment (byte[],int,int) <0x0006f>
  at System.IO.FileStream.ReadInternal (byte[],int,int) <0x0002f>
  at (wrapper runtime-invoke) <Module>.runtime_invoke_int__this___object_int_int (object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:


Debug info from gdb:

Mono support loaded.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0xb519a430 (LWP 25526)]
[New Thread 0xb53ff430 (LWP 25523)]
[New Thread 0xb52ba430 (LWP 25185)]
[New Thread 0xb52da430 (LWP 25184)]
[New Thread 0xb553c430 (LWP 25182)]
[New Thread 0xb5bef430 (LWP 25181)]
0xb6f1b494 in pthread_cond_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
  Id   Target Id         Frame
  7    Thread 0xb5bef430 (LWP 25181) "mono" 0xb6f1d700 in sem_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
  6    Thread 0xb553c430 (LWP 25182) "mono" 0xb6f1f250 in nanosleep () from /lib/arm-linux-gnueabihf/libpthread.so.0
  5    Thread 0xb52da430 (LWP 25184) "mono" 0xb6e83e84 in epoll_wait () from /lib/arm-linux-gnueabihf/libc.so.6
  4    Thread 0xb52ba430 (LWP 25185) "mono" 0xb6f1d954 in sem_timedwait () from /lib/arm-linux-gnueabihf/libpthread.so.0
  3    Thread 0xb53ff430 (LWP 25523) "mono" 0xb6f1fa3c in waitpid () from /lib/arm-linux-gnueabihf/libpthread.so.0
  2    Thread 0xb519a430 (LWP 25526) "mono" 0xb6f1d954 in sem_timedwait () from /lib/arm-linux-gnueabihf/libpthread.so.0
* 1    Thread 0xb6fef000 (LWP 25180) "mono" 0xb6f1b494 in pthread_cond_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0

Thread 7 (Thread 0xb5bef430 (LWP 25181)):
#0  0xb6f1d700 in sem_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1  0x001fb300 in mono_sem_wait (sem=0x2efc34, alertable=1) at mono-semaphore.c:119
#2  0x0017a214 in finalizer_thread (unused=<optimized out>) at gc.c:1073
#3  0x0015f1b4 in start_wrapper_internal (data=0x1b1b840) at threads.c:616
#4  start_wrapper (data=0x1b1b840) at threads.c:661
#5  0x001f1400 in thread_start_routine (args=0x1ad6628) at wthreads.c:294
#6  0x001ff50c in inner_start_thread (arg=<optimized out>) at mono-threads-posix.c:49
#7  0xb6f16bfc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
#8  0xb6e83758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#9  0xb6e83758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 6 (Thread 0xb553c430 (LWP 25182)):
#0  0xb6f1f250 in nanosleep () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1  0xb6f1e044 in __pthread_enable_asynccancel () from /lib/arm-linux-gnueabihf/libpthread.so.0
#2  0x001f05e0 in SleepEx (ms=<optimized out>, alertable=162) at wthreads.c:842
#3  0x00160b50 in monitor_thread (unused=<optimized out>) at threadpool.c:779
#4  0x0015f1b4 in start_wrapper_internal (data=0x1d3e5e8) at threads.c:616
#5  start_wrapper (data=0x1d3e5e8) at threads.c:661
#6  0x001f1400 in thread_start_routine (args=0x1ad67d8) at wthreads.c:294
#7  0x001ff50c in inner_start_thread (arg=<optimized out>) at mono-threads-posix.c:49
#8  0xb6f16bfc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
#9  0xb6e83758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#10 0xb6e83758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 5 (Thread 0xb52da430 (LWP 25184)):
#0  0xb6e83e84 in epoll_wait () from /lib/arm-linux-gnueabihf/libc.so.6
#1  0x001614d4 in tp_epoll_wait (p=0x2efa7c) at ../../mono/metadata/tpool-epoll.c:118
#2  0x0015f1b4 in start_wrapper_internal (data=0x1d94f10) at threads.c:616
#3  start_wrapper (data=0x1d94f10) at threads.c:661
#4  0x001f1400 in thread_start_routine (args=0x1ad6b38) at wthreads.c:294
#5  0x001ff50c in inner_start_thread (arg=<optimized out>) at mono-threads-posix.c:49
#6  0xb6f16bfc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
#7  0xb6e83758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#8  0xb6e83758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 4 (Thread 0xb52ba430 (LWP 25185)):
#0  0xb6f1d954 in sem_timedwait () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1  0x001fb3e0 in mono_sem_timedwait (sem=0x2ef9fc, timeout_ms=<optimized out>, alertable=1) at mono-semaphore.c:82
#2  0x00163514 in async_invoke_thread (data=0xb6e2ce00) at threadpool.c:1565
#3  0x0015f1b4 in start_wrapper_internal (data=0x1d95248) at threads.c:616
#4  start_wrapper (data=0x1d95248) at threads.c:661
#5  0x001f1400 in thread_start_routine (args=0x1ad6bc8) at wthreads.c:294
#6  0x001ff50c in inner_start_thread (arg=<optimized out>) at mono-threads-posix.c:49
#7  0xb6f16bfc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
#8  0xb6e83758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#9  0xb6e83758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 3 (Thread 0xb53ff430 (LWP 25523)):
#0  0xb6f1fa3c in waitpid () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1  0x000b12ac in mono_handle_native_sigsegv (signal=<optimized out>, ctx=<optimized out>) at mini-exceptions.c:2299
#2  0x0002780c in mono_sigsegv_signal_handler (_dummy=11, info=0xb53fe548, context=0xb53fe5c8) at mini.c:6777
#3  <signal handler called>
#4  mono_array_get_byte_length (array=0xb664b9e0) at icall.c:6121
#5  ves_icall_System_Buffer_BlockCopyInternal (src=0xb4b89010, src_offset=<optimized out>, dest=<optimized out>, dest_offset=<optimized out>, count=4096) at icall.c:6192
#6  0xb5786870 in ?? ()
Cannot access memory at address 0xff8

=================================================================
Got a SIGSEGV 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


Mono is build from latest sources from Git:

Mono Runtime Engine version 3.2.7 (master/0aa1d4f Sun Jan 12 21:09:56 CET 2014)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       normal
        Notifications: epoll
        Architecture:  armel,vfp+hard
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            sgen
Comment 1 Zoltan Varga 2014-01-14 08:55:19 UTC
This is probably a GC problem. Can you create some kind of test case which reproduces the problem ?
Comment 2 Jiri {x2} Cincura 2014-01-14 08:58:42 UTC
I'm not sure. I can't even replicate it every time. I'll try my best.
Comment 3 Andres G. Aragoneses 2014-01-14 09:03:35 UTC
Zoltan,

What the user is reporting here is actually a build failure. See: 

http://stackoverflow.com/questions/20990357/mono-showing-often-wapi-handle-ref-wapi-handle-unref-full-errors

(The part where he tries to build 3.2.7)


And I'm also having troubles building master (and other people too, see http://lists.ximian.com/pipermail/mono-devel-list/2014-January/041065.html), and I'm on Linux 64bits, so I think this bug is not only in ARM.

I've been trying to bisect my SIGSEV [1], and I think I've found the culprit to be in this commit from you:

https://github.com/mono/mono/commit/a0afa38296b8a3b0382bf34ce777357d2553c0f0

Because if I go back to the previous commit, the build works again:

https://github.com/mono/mono/commit/b71c0d6afc85ec1512d89692ca09dfc1692494cd

(jiri, you might want to try building up until this commit, not master HEAD.)


[1] Not exactly the same SIGSEV as above, but I think they're very related:

if test -w /home/knocte/Documents/Code/OpenSource/mono/mcs; then :; else chmod -R +w /home/knocte/Documents/Code/OpenSource/mono/mcs; fi
cd /home/knocte/Documents/Code/OpenSource/mono/mcs && make --no-print-directory -s NO_DIR_CHECK=1 PROFILES='net_2_0 net_3_5 net_4_0 net_4_5 xbuild_12  ' CC='gcc' all-profiles
Bootstrap compiler: Mono C# compiler version 3.2.5.0
AOT     [build] mscorlib.dll.so
Stacktrace:


Native stacktrace:

	/home/knocte/Documents/Code/OpenSource/mono/mono/mini/mono() [0x4adeba]
	/home/knocte/Documents/Code/OpenSource/mono/mono/mini/mono() [0x50666f]
	/home/knocte/Documents/Code/OpenSource/mono/mono/mini/mono() [0x420f07]
	/lib/x86_64-linux-gnu/libpthread.so.0(+0xfbd0) [0x2ad4cf8dfbd0]
	/lib/x86_64-linux-gnu/libpthread.so.0(pthread_join+0x24) [0x2ad4cf8d9184]
	/home/knocte/Documents/Code/OpenSource/mono/mono/mini/mono() [0x5a468f]
	/home/knocte/Documents/Code/OpenSource/mono/mono/mini/mono(mono_runtime_cleanup+0xe) [0x59c03e]
	/home/knocte/Documents/Code/OpenSource/mono/mono/mini/mono() [0x419616]
	/home/knocte/Documents/Code/OpenSource/mono/mono/mini/mono(mono_main+0x1151) [0x483f31]
	/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x2ad4cfb0eea5]
	/home/knocte/Documents/Code/OpenSource/mono/mono/mini/mono() [0x419139]

Debug info from gdb:

Could not attach to process.  If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
No threads.

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

Mono Ahead of Time compiler - compiling assembly /home/knocte/Documents/Code/OpenSource/mono/mcs/class/lib/build/mscorlib.dll
Code: 3361782 Info: 96939 Ex Info: 1576324 Unwind Info: 6226 Class Info: 76136 PLT: 5577 GOT Info: 100586 GOT: 97784 Offsets: 196751
Compiled: 20275/20275 (100%), No GOT slots: 13757 (67%), Direct calls: 29110 (82%)
JIT time: 1340 ms, Generation time: 604 ms, Assembly+Link time: 111 ms.
Aborted (core dumped)
make[7]: *** [../../class/lib/build//mscorlib.dll.so] Error 1
make[6]: *** [do-all] Error 2
make[5]: *** [all-recursive] Error 1
make[4]: *** [profile-do--build--all] Error 2
make[3]: *** [profiles-do--all] Error 2
make[2]: *** [all-local] Error 2
make[2]: Leaving directory `/home/knocte/Documents/Code/OpenSource/mono/runtime'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/knocte/Documents/Code/OpenSource/mono'
make: *** [all] Error 2

Any help is appreciated.
Comment 4 Zoltan Varga 2014-01-14 12:37:08 UTC
Commited to some fixes to the problems caused by
https://github.com/mono/mono/commit/a0afa38296b8a3b0382bf34ce777357d2553c0f0
Comment 5 Jiri {x2} Cincura 2014-01-14 13:11:16 UTC
I checked out the a0afa38296b8a3b0382bf34ce777357d2553c0f0 commit. Building now, it takes a couple of hours on Raspberry. I'll rerun the application and I'll report back.
Comment 6 Andres G. Aragoneses 2014-01-14 17:50:35 UTC
> Commited to some fixes to the problems caused by a0afa3829

Thanks Zoltan, that seems to fix the build problems for me. Hopefully Jiri can test now soon if he still reproduces this bug.
Comment 7 Jiri {x2} Cincura 2014-01-16 09:19:01 UTC
Nope. That didn't fixed the problem:

Stacktrace:

  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) System.Buffer.BlockCopyInternal (System.Array,int,System.Array,int,int) <0xffffffff>
  at System.IO.FileStream.ReadSegment (byte[],int,int) <0x0006f>
  at System.IO.FileStream.ReadInternal (byte[],int,int) <0x0002f>
  at (wrapper runtime-invoke) <Module>.runtime_invoke_int__this___object_int_int (object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:


Debug info from gdb:

Mono support loaded.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0xb50f1430 (LWP 24179)]
[New Thread 0xb5211430 (LWP 24014)]
[New Thread 0xb5231430 (LWP 24013)]
[New Thread 0xb5383430 (LWP 24011)]
[New Thread 0xb6a23430 (LWP 24010)]
0xb6e70494 in pthread_cond_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
  Id   Target Id         Frame
  6    Thread 0xb6a23430 (LWP 24010) "mono" 0xb6e72700 in sem_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
  5    Thread 0xb5383430 (LWP 24011) "mono" 0xb6e74250 in nanosleep () from /lib/arm-linux-gnueabihf/libpthread.so.0
  4    Thread 0xb5231430 (LWP 24013) "mono" 0xb6dd8e84 in epoll_wait () from /lib/arm-linux-gnueabihf/libc.so.6
  3    Thread 0xb5211430 (LWP 24014) "mono" 0xb6e72954 in sem_timedwait () from /lib/arm-linux-gnueabihf/libpthread.so.0
  2    Thread 0xb50f1430 (LWP 24179) "mono" 0xb6e74a3c in waitpid () from /lib/arm-linux-gnueabihf/libpthread.so.0
* 1    Thread 0xb6f44000 (LWP 24009) "mono" 0xb6e70494 in pthread_cond_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0

Thread 6 (Thread 0xb6a23430 (LWP 24010)):
#0  0xb6e72700 in sem_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1  0x001fb140 in mono_sem_wait (sem=0x2efa94, alertable=1) at mono-semaphore.c:119
#2  0x0017a054 in finalizer_thread (unused=<optimized out>) at gc.c:1073
#3  0x0015f014 in start_wrapper_internal (data=0x133f840) at threads.c:617
#4  start_wrapper (data=0x133f840) at threads.c:662
#5  0x001f1240 in thread_start_routine (args=0x12fa6b8) at wthreads.c:294
#6  0x001ff394 in inner_start_thread (arg=0x12fa6ac) at mono-threads-posix.c:49
#7  0xb6e6bbfc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
#8  0xb6dd8758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#9  0xb6dd8758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 5 (Thread 0xb5383430 (LWP 24011)):
#0  0xb6e74250 in nanosleep () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1  0xb6e73044 in __pthread_enable_asynccancel () from /lib/arm-linux-gnueabihf/libpthread.so.0
#2  0x001f0420 in SleepEx (ms=<optimized out>, alertable=162) at wthreads.c:842
#3  0x00160990 in monitor_thread (unused=<optimized out>) at threadpool.c:779
#4  0x0015f014 in start_wrapper_internal (data=0x1587580) at threads.c:617
#5  start_wrapper (data=0x1587580) at threads.c:662
#6  0x001f1240 in thread_start_routine (args=0x12fa8f8) at wthreads.c:294
#7  0x001ff394 in inner_start_thread (arg=0x12fa8ec) at mono-threads-posix.c:49
#8  0xb6e6bbfc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
#9  0xb6dd8758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#10 0xb6dd8758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 4 (Thread 0xb5231430 (LWP 24013)):
#0  0xb6dd8e84 in epoll_wait () from /lib/arm-linux-gnueabihf/libc.so.6
#1  0x00161314 in tp_epoll_wait (p=0x2ef8dc) at ../../mono/metadata/tpool-epoll.c:118
#2  0x0015f014 in start_wrapper_internal (data=0x15a2c60) at threads.c:617
#3  start_wrapper (data=0x15a2c60) at threads.c:662
#4  0x001f1240 in thread_start_routine (args=0x12fad78) at wthreads.c:294
#5  0x001ff394 in inner_start_thread (arg=0x12fad6c) at mono-threads-posix.c:49
#6  0xb6e6bbfc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
#7  0xb6dd8758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#8  0xb6dd8758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 3 (Thread 0xb5211430 (LWP 24014)):
#0  0xb6e72954 in sem_timedwait () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1  0x001fb220 in mono_sem_timedwait (sem=0x2ef85c, timeout_ms=<optimized out>, alertable=1) at mono-semaphore.c:82
#2  0x00163354 in async_invoke_thread (data=0xb6d81e00) at threadpool.c:1565
#3  0x0015f014 in start_wrapper_internal (data=0x1598270) at threads.c:617
#4  start_wrapper (data=0x1598270) at threads.c:662
#5  0x001f1240 in thread_start_routine (args=0x12fae98) at wthreads.c:294
#6  0x001ff394 in inner_start_thread (arg=0x12fae8c) at mono-threads-posix.c:49
#7  0xb6e6bbfc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
#8  0xb6dd8758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#9  0xb6dd8758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 2 (Thread 0xb50f1430 (LWP 24179)):
#0  0xb6e74a3c in waitpid () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1  0x000b12dc in mono_handle_native_sigsegv (signal=<optimized out>, ctx=<optimized out>) at mini-exceptions.c:2299
#2  0x0002783c in mono_sigsegv_signal_handler (_dummy=11, info=0xb50f0548, context=0xb50f05c8) at mini.c:6777
#3  <signal handler called>
#4  mono_array_get_byte_length (array=0xb64b09c0) at icall.c:6121
#5  ves_icall_System_Buffer_BlockCopyInternal (src=0xb54d8010, src_offset=<optimized out>, dest=<optimized out>, dest_offset=<optimized out>, count=4096) at icall.c:6192
#6  0xb681a868 in ?? ()
Cannot access memory at address 0xff8

=================================================================
Got a SIGSEGV 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
Comment 8 Jiri {x2} Cincura 2014-01-17 00:32:53 UTC
I tried also b71c0d6afc85ec1512d89692ca09dfc1692494cd Andres mentioned. This fails with slightly differently:

Stacktrace:

  at <unknown> <0xffffffff>
  at System.Threading.Tasks.TaskFactory`1<int>.InnerInvoke (System.Threading.Tasks.TaskCompletionSource`1<int>,System.Func`2<System.IAsyncResult, int>,System.IAsyncResult) <0x00037>
  at System.Threading.Tasks.TaskFactory`1/<FromAsyncBeginEnd>c__AnonStorey5`3<int, byte[], int, int>.<>m__0 (System.IAsyncResult) <0x00037>
  at (wrapper runtime-invoke) <Module>.runtime_invoke_void__this___object (object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:


Debug info from gdb:

Mono support loaded.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0xb5363430 (LWP 21466)]
[New Thread 0xb5211430 (LWP 21229)]
[New Thread 0xb5231430 (LWP 21228)]
[New Thread 0xb5383430 (LWP 21226)]
[New Thread 0xb6a17430 (LWP 21225)]
0xb6e64494 in pthread_cond_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
  Id   Target Id         Frame
  6    Thread 0xb6a17430 (LWP 21225) "mono" 0xb6e66700 in sem_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
  5    Thread 0xb5383430 (LWP 21226) "mono" 0xb6e68250 in nanosleep () from /lib/arm-linux-gnueabihf/libpthread.so.0
  4    Thread 0xb5231430 (LWP 21228) "mono" 0xb6dcce84 in epoll_wait () from /lib/arm-linux-gnueabihf/libc.so.6
  3    Thread 0xb5211430 (LWP 21229) "mono" 0xb6e66954 in sem_timedwait () from /lib/arm-linux-gnueabihf/libpthread.so.0
  2    Thread 0xb5363430 (LWP 21466) "mono" 0xb6e68a3c in waitpid () from /lib/arm-linux-gnueabihf/libpthread.so.0
* 1    Thread 0xb6f38000 (LWP 21224) "mono" 0xb6e64494 in pthread_cond_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0

Thread 6 (Thread 0xb6a17430 (LWP 21225)):
#0  0xb6e66700 in sem_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1  0x001fb0c0 in mono_sem_wait (sem=0x2ef9d4, alertable=1) at mono-semaphore.c:119
#2  0x00179fd4 in finalizer_thread (unused=<optimized out>) at gc.c:1073
#3  0x0015ef88 in start_wrapper_internal (data=0x4cb840) at threads.c:617
#4  start_wrapper (data=0x4cb840) at threads.c:662
#5  0x001f11c0 in thread_start_routine (args=0x4866b8) at wthreads.c:294
#6  0x001ff2cc in inner_start_thread (arg=<optimized out>) at mono-threads-posix.c:49
#7  0xb6e5fbfc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
#8  0xb6dcc758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#9  0xb6dcc758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 5 (Thread 0xb5383430 (LWP 21226)):
#0  0xb6e68250 in nanosleep () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1  0xb6e67044 in __pthread_enable_asynccancel () from /lib/arm-linux-gnueabihf/libpthread.so.0
#2  0x001f03a0 in SleepEx (ms=<optimized out>, alertable=162) at wthreads.c:842
#3  0x00160910 in monitor_thread (unused=<optimized out>) at threadpool.c:779
#4  0x0015ef88 in start_wrapper_internal (data=0x6eb328) at threads.c:617
#5  start_wrapper (data=0x6eb328) at threads.c:662
#6  0x001f11c0 in thread_start_routine (args=0x4868f8) at wthreads.c:294
#7  0x001ff2cc in inner_start_thread (arg=<optimized out>) at mono-threads-posix.c:49
#8  0xb6e5fbfc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
#9  0xb6dcc758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#10 0xb6dcc758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 4 (Thread 0xb5231430 (LWP 21228)):
#0  0xb6dcce84 in epoll_wait () from /lib/arm-linux-gnueabihf/libc.so.6
#1  0x00161294 in tp_epoll_wait (p=0x2ef81c) at ../../mono/metadata/tpool-epoll.c:118
#2  0x0015ef88 in start_wrapper_internal (data=0x744820) at threads.c:617
#3  start_wrapper (data=0x744820) at threads.c:662
#4  0x001f11c0 in thread_start_routine (args=0x486d78) at wthreads.c:294
#5  0x001ff2cc in inner_start_thread (arg=<optimized out>) at mono-threads-posix.c:49
#6  0xb6e5fbfc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
#7  0xb6dcc758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#8  0xb6dcc758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 3 (Thread 0xb5211430 (LWP 21229)):
#0  0xb6e66954 in sem_timedwait () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1  0x001fb1a0 in mono_sem_timedwait (sem=0x2ef79c, timeout_ms=<optimized out>, alertable=1) at mono-semaphore.c:82
#2  0x001632d4 in async_invoke_thread (data=0xb6d75e00) at threadpool.c:1565
#3  0x0015ef88 in start_wrapper_internal (data=0x7425f8) at threads.c:617
#4  start_wrapper (data=0x7425f8) at threads.c:662
#5  0x001f11c0 in thread_start_routine (args=0x486e98) at wthreads.c:294
#6  0x001ff2cc in inner_start_thread (arg=<optimized out>) at mono-threads-posix.c:49
#7  0xb6e5fbfc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
#8  0xb6dcc758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#9  0xb6dcc758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 2 (Thread 0xb5363430 (LWP 21466)):
#0  0xb6e68a3c in waitpid () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1  0x000b12ac in mono_handle_native_sigsegv (signal=<optimized out>, ctx=<optimized out>) at mini-exceptions.c:2299
#2  0x0002780c in mono_sigsegv_signal_handler (_dummy=11, info=0xb53625b8, context=0xb5362638) at mini.c:6777
#3  <signal handler called>
#4  0x000b3ee4 in mono_delegate_trampoline (regs=<optimized out>, code=<optimized out>, tramp_data=<optimized out>, tramp=<optimized out>) at mini-trampolines.c:1004
#5  0xb6b7c858 in ?? ()
#6  0xb6b7c858 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 1 (Thread 0xb6f38000 (LWP 21224)):
#0  0xb6e64494 in pthread_cond_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1  0x001db330 in _wapi_handle_timedwait_signal_handle (handle=0x4cd, timeout=0x0, alertable=1, poll=<optimized out>) at handles.c:1588
#2  0x001ee1a0 in WaitForSingleObjectEx (handle=0x1ee1a0, timeout=3053492, alertable=1229) at wait.c:196
#3  0x0015cfc0 in mono_wait_uninterrupted (thread=0xb6aa8010, multiple=-1235989496, numhandles=1, handles=0xbef0f74c, waitall=0, ms=-1, alertable=1) at threads.c:1454
#4  0x0015e990 in ves_icall_System_Threading_WaitHandle_WaitOne_internal (this=<optimized out>, handle=0x4cb4d8, ms=-1, exitContext=<optimized out>) at threads.c:1586
#5  0xb5391548 in ?? ()
#6  0xb5391548 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

=================================================================
Got a SIGSEGV 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
Comment 9 Andres G. Aragoneses 2014-01-17 07:31:26 UTC
Jiri, both failures (in comment#8 and comment#7) happen when building mono? or when running your app?
Comment 10 Jiri {x2} Cincura 2014-01-17 07:34:55 UTC
Always when running application. Build is/was fine.
Comment 11 Andres G. Aragoneses 2014-01-17 07:37:23 UTC
Ok, then you need to run your app with gdb, let it crash, and at that point obtain a backtrace.

(Do it with mono master, forget about b71c0d6afc85ec1512d for now)
Comment 12 Jiri {x2} Cincura 2014-01-17 08:08:48 UTC
Traces that are above are not enough?
Comment 13 Andres G. Aragoneses 2014-01-17 08:36:00 UTC
From those traces it is not clear which of the threads is the one that crashed, unless I'm missing something?
Comment 14 Jiri {x2} Cincura 2014-01-17 08:39:53 UTC
Well, I'm not gdb expert. But I'm now building master and I'll attach gdb to the application running. Let's see whether I get something more.
Comment 15 Jiri {x2} Cincura 2014-01-20 12:39:24 UTC
The application run now for roughly two days without SIGSEGV crashing. It stopped (deadlocked/livelocked) after bunch of _wapi_handle_ref/_wapi_handle_unref_full errors as described http://stackoverflow.com/questions/20990357/mono-showing-often-wapi-handle-ref-wapi-handle-unref-full-errors . Should I report this one separately? I have trace for it.

I'm running it again to see whether I'll be able to get the crash and have a backtrace. Maybe it's because the debugger is attached?
Comment 16 Andres G. Aragoneses 2014-01-20 12:49:54 UTC
> Should I report this one separately? I have trace for it

Yes please.

> Maybe it's because the debugger is attached?

Sadly, that is very likely, in which case we're talking about a "heisenbug", a bug which disappears when you try to examine it :) In those cases, the best way to deal with it is to put printf() calls around the place where it seems it's crashing, to try to determine it without a debugger. (But if you put too many printfs, the bug may hide again.)
Comment 17 Jiri {x2} Cincura 2014-01-20 13:00:13 UTC
I'll run it under gdb once more. Either it will fail again with https://bugzilla.xamarin.com/show_bug.cgi?id=17333 or the SIGSEGV. If the first, I'll try to run without debugger and attach it later - might or might not help.
Comment 18 Jiri {x2} Cincura 2014-01-26 06:28:58 UTC
I ran the application two times again. No SIGSEGV. Just stopped as in https://bugzilla.xamarin.com/show_bug.cgi?id=17333 . Still running on:

Mono JIT compiler version 3.2.7 (master/47071c9 Fri Jan 17 20:03:13 CET 2014)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       normal
        Notifications: epoll
        Architecture:  armel,vfp+hard
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            sgen
 
Is there something I might try? And if it's OK, we can close this ticket.
Comment 19 Andres G. Aragoneses 2014-01-26 06:43:02 UTC
No SIGSEGV, inside gdb, or outside gdb?
Comment 20 Jiri {x2} Cincura 2014-01-26 09:07:15 UTC
Nor inside, nor outside. I think that's good.
Comment 21 Andres G. Aragoneses 2014-01-26 09:09:14 UTC
Yep, you can close it then! Reopen if you see it again.
Comment 22 Jiri {x2} Cincura 2014-04-28 01:15:26 UTC
I see this again on 3.2.8 from official package (detailed version below). I'm running it in gdb to get more info.


Stacktrace:

  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) System.Buffer.BlockCopyInternal (System.Array,int,System.Array,int,int) <0xffffffff>
  at System.IO.FileStream.ReadSegment (byte[],int,int) <0x0006f>
  at System.IO.FileStream.ReadInternal (byte[],int,int) <0x0002f>
  at (wrapper runtime-invoke) <Module>.runtime_invoke_int__this___object_int_int (object,intptr,intptr,intptr) <0xffffffff>


Mono JIT compiler version 3.2.8 (Debian 3.2.8+dfsg-4+rpi1)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       normal
        Notifications: epoll
        Architecture:  armel,vfp+hard
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            sgen
Comment 23 Zoltan Varga 2014-04-28 05:02:15 UTC
3.2.8 never worked with armhf, please try 3.4.0.
Comment 24 Jiri {x2} Cincura 2014-04-28 05:12:37 UTC
Interesting. I saw in releases note of 3.2.7 "Initial support for the hardfp ABI on ARM.". I'll try to build 3.4 from sources.
Comment 25 Alex Rønne Petersen 2015-05-07 20:29:30 UTC
Is this still an issue on Mono master?
Comment 26 Alex Rønne Petersen 2016-04-21 03:21:23 UTC
Closing due to lack of response. Feel free to reopen if it is still reproducible.