[Mono-dev] s390x - delegate-async-exit

[Ludovic Henry]

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 <ludovic at xamarin.com> wrote:

>
> ---------- Forwarded message ----------
> From: Neale Ferguson <neale at sinenomine.net>
> Date: Thu, Aug 6, 2015 at 11:38 AM
> Subject: Re: [Mono-dev] s390x - delegate-async-exit
> To: Ludovic Henry <ludovic at 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 <ludovic at xamarin.com>
> Date: Thursday, August 6, 2015 at 11:27 AM
> To: Neale Ferguson <neale at sinenomine.net>
> Cc: Mono-Devel <mono-devel-list at 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 <neale at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20150806/3f710b71/attachment.html>