Hi Neal,
So it appears the use of MONO_OBJECT_SETREF on end_invoke_called is wrong
as it is going to write on 8 bytes, instead of 1.
I added an assertion to this macro to test the size of the field we are
assigning to try to avoid further bugs.
Can you try with abad8aaabda16bde4adda57c6533833fca23791a to check if its
working now?
Thank you very much!
On Thu, Aug 6, 2015 at 2:08 PM, Ludovic Henry <ludo...@xamarin.com> wrote:
>
> ---------- Forwarded message ----------
> From: Neale Ferguson <ne...@sinenomine.net>
> Date: Thu, Aug 6, 2015 at 11:38 AM
> Subject: Re: [Mono-dev] s390x - delegate-async-exit
> To: Ludovic Henry <ludo...@xamarin.com>
>
>
> I assume you meant ares and not async_result:
>
> (gdb) p mono_object_describe_fields((MonoObject*)ares)
>
> At 0x3fffd400698 (ofs: 16) async_state: String at 0x3fffba70150, length:
> 3, 'foo'
>
> At 0x3fffd4006a0 (ofs: 24) handle: System.Threading.ManualResetEvent
> object at 0x3fffd400910 (klass: 0x8041ad80)
>
> At 0x3fffd4006a8 (ofs: 32) async_delegate: foo/foo_delegate object at
> 0x3fffd400488 (klass: 0x80473210)
>
> At 0x3fffd4006b0 (ofs: 40) data: (nil)
>
> At 0x3fffd4006b8 (ofs: 48) object_data: System.MonoAsyncCall object at
> 0x3fffd400648 (klass: 0x8047b370)
>
> At 0x3fffd4006c0 (ofs: 56) sync_completed: False (0)
>
> At 0x3fffd4006c1 (ofs: 57) completed: True (1)
>
> At 0x3fffd4006c2 (ofs: 58) endinvoke_called: False (0)
>
> At 0x3fffd4006c8 (ofs: 64) async_callback: (null)
>
> At 0x3fffd4006d0 (ofs: 72) current: System.Threading.ExecutionContext
> object at 0x3fffd400740 (klass: 0x8041e870)
>
> At 0x3fffd4006d8 (ofs: 80) original: (null)
>
> At 0x3fffd4006e0 (ofs: 88) add_time: 0
>
> At 0x3fffd4006e8 (ofs: 96) call_message: (null)
>
> At 0x3fffd4006f0 (ofs: 104) message_ctrl: (null)
>
> At 0x3fffd4006f8 (ofs: 112) reply_message: (null)
>
> At 0x3fffd400700 (ofs: 120) orig_cb: (null)
>
> $1 = void
>
> (gdb) p (long long)(void*)&ares->async_callback - (long long)(void*)ares
>
> $2 = 64
>
> From: Ludovic Henry <ludo...@xamarin.com>
> Date: Thursday, August 6, 2015 at 11:27 AM
> To: Neale Ferguson <ne...@sinenomine.net>
> Cc: Mono-Devel <mono-devel-list@lists.ximian.com>
> Subject: Re: [Mono-dev] s390x - delegate-async-exit
>
> 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.
>
>
>
> --
> Ludovic Henry
> Runtime Software Engineer
> Xamarin, Inc.
>
--
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
