Hey Neale,
When hitting threadpool-ms.c:1310, could you print the result of the
following 2 commands in gdb (or equivalent):
p mono_object_describe_fields((MonoObject*)async_result)
p (long long)(void*)&async_result->async_callback - (long
long)(void*)async_result
I suspect the memory layout on s390x of the native struct is not the same
as the memory layout of the managed object, leading to memory corruption
like bugs.
Thank you!
Ludovic
On Wed, Aug 5, 2015 at 5:47 PM, Neale Ferguson <ne...@sinenomine.net> wrote:
> Further investigation shows the value being set here:
>
> 0x80200bb2 is in mono_gc_wbarrier_set_arrayref (sgen-mono.c:171).
> 166 void
> 167 mono_gc_wbarrier_set_arrayref (MonoArray *arr, gpointer slot_ptr,
> MonoObject* value)
> 168 {
> 169 HEAVY_STAT (++stat_wbarrier_set_arrayref);
> 170 if (sgen_ptr_in_nursery (slot_ptr)) {
> 171 *(void**)slot_ptr = value;
> 172 return;
> 173 }
> 174 SGEN_LOG (8, "Adding remset at %p", slot_ptr);
> 175 if (value)
>
>
> This is called from:
>
> 0x801a5c22 is in mono_threadpool_ms_end_invoke (threadpool-ms.c:1310).
> 1305 }
> 1306
> 1307 MONO_OBJECT_SETREF (ares, endinvoke_called, 1);
> 1308
> 1309 /* wait until we are really finished */
> 1310 if (ares->completed) {
> 1311 mono_monitor_exit ((MonoObject *) ares);
> 1312 } else {
> 1313 gpointer wait_event;
> 1314 if (ares->handle) {
>
>
> Now the fact that the scan is pulling the value 0x1000000000000 this would
> indicate that the slot_ptr (ares) is not aligned on a pointer boundary so
> the calculation of this location must be incorrect.
> Neale
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
--
Ludovic Henry
Runtime Software Engineer
Xamarin, Inc.
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
