<div dir="ltr"><div>Time for a status update on this issue. Sadly no good news at all.</div><div><br></div><div>Long story short on my mono tests. Managed to get no-managed-allocator working, but disabling TLABs didn't have any noticeable effect. Neither did adding a memory barrier to the mono_100ns_ticks method and some other attempts.</div><div>Btw already checked boehm earlier, test runs a lot longer but succeeds without crash.<br></div><div><br></div><div>At that point I decided it was better to investigate the kernel again to see what really changed under the hood. In the hopes of finding out where I should focus my investigation in mono.</div><div><br></div><div>I've been looking at the gcc compiled assembly code. Also checked during runtime, the lfence instruction is properly emitted, so the theory about the alternative_2 not emitting it properly is off the table too.<br></div><div>After a few days I discovered that the commit indirectly caused gcc to inline another method (vread_pvclock), this obviously changed the assembly code.</div><div><br></div><div>Ever since then, I've been playing around with those vdso methods. Quite literally compiled the kernel dozens of times.</div><div>With __always_inline on vread_pvclock, mono crashed. With noinline on vread_pvclock, mono doesn't crash. Weirdest part is that the pvclock isn't even used during my tests.</div><div>During inline the vdso object increases in size, but if I force noinline and add nops to increase the vdso size, mono doesn't crash either. Another theory shot down.<br></div><div>I've looked at the assembly code differences between compiles, but so far I haven't been able to find a functional difference. I'm planning to go over the entire assembly code one more time, see if I missed something, but that's a rather tedious process.</div><div><br></div><div>So I'm pretty much clueless about how this could possibly affect the way mono runs, yet it does.</div><div></div><div><br></div><div>I'm aware my tests with the kernel doesn't directly involve mono, but if there is anyone with some expertise willing to hop in or give suggestions on how to proceed. Please do tell.</div>I'm already miles outside of my area of expertise and I fear what happens if this kernel version becomes mainstream and hundreds of mono users start being affected by odd, untraceable crashes.<div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 24, 2015 at 3:19 PM, Rafael Teixeira <span dir="ltr"><<a href="mailto:monoman@gmail.com" target="_blank">monoman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">AFAIR, memory barriers are CORE to the new sgen GC logic for managing what/when to collect. Not sure if you still can build with the conservative (Boehm) GC to compare results, or gain more time to find the real solution...</p><div class="HOEnZb"><div class="h5">
<br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 23, 2015, 18:06 Taloth Saldono <<a href="mailto:talothsaldono@gmail.com" target="_blank">talothsaldono@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey Greg,<div><br></div><div>With my current test case it crashes anywhere between 0.1 and 30 sec, occasionally longer.<br></div><div>If I run my test case till it crashes, 10 times in a row, measuring the total run time:</div><div>vanilla = 3m9.216s 2m26.571s 2m31.168s 3m8.670s</div><div>clear-at-gc = 1m50.81s 2m01.85s 1m10.21s 1m10.21s</div><div>disable-minor = 0m16.74s 0m16.32s (duh, more major collections. the reverse happens if you increase the nursery size.)</div><div><br></div><div><div>So.... yeah, clear-at-gc actually makes it worse. ;)</div></div><div><br></div><div>It quite possibly has something to do with the GC, but i'm trying to find the link with that rdtsc instruction.</div><div>Assuming the tsc isn't used in some convoluted way, it means it should be a missing memory barrier somewhere.</div></div><div dir="ltr"><div><br></div><div>Taloth</div></div><div dir="ltr"><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 23, 2015 at 2:11 PM, Greg Young <span dir="ltr"><<a href="mailto:gregoryyoung1@gmail.com" target="_blank">gregoryyoung1@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We have seen some similar crashes of mono in linux (ubuntu and amazon linux).<br>
<br>
One thing we have done that greatly reduces the frequency of the<br>
crashes so far (removed 95%+ of them) is. MONO_GC_DEBUG=clear-at-gc<br>
<br>
There is an issue here as well<br>
<a href="https://bugzilla.xamarin.com/show_bug.cgi?id=18151" rel="noreferrer" target="_blank">https://bugzilla.xamarin.com/show_bug.cgi?id=18151</a> that is likely<br>
related.<br>
<span><br>
On Thu, Jul 23, 2015 at 3:03 PM, Taloth Saldono <<a href="mailto:talothsaldono@gmail.com" target="_blank">talothsaldono@gmail.com</a>> wrote:<br>
> Hey guys,<br>
><br>
> (Initially I incorrectly posted this to the mono-list, so for those<br>
> receiving this message twice, my apologies.)<br>
><br>
> I'm looking for a mono expert on the managed threading system, hopefully you<br>
> can give me a pointer to where to look.<br>
><br>
> The problem a couple of my users experience is that since linux kernel 4.1<br>
> mono crashes in a reproducible manner. (Using test case bug-18026 in a loop,<br>
> which is a threadpool stress-test)<br>
><br>
> A similar problem occurred in 3.13.0 but that was fixed by backporting some<br>
> commits in the ubuntu kernel. (See<br>
</span><span>> <a href="https://bugzilla.xamarin.com/show_bug.cgi?id=29212" rel="noreferrer" target="_blank">https://bugzilla.xamarin.com/show_bug.cgi?id=29212</a>)<br>
><br>
> Initially I believed that in 4.1 those commits were reverted, but tests<br>
> indicated that wasn't the cause.<br>
> So I did a full bisect on linux 4.0-4.1 on a 64-bit Ubuntu 14.04.2<br>
> Virtualbox. (~13 compiles of the kernel, took a couple of days)<br>
> And it ended up on<br>
</span><div><div>> <a href="https://github.com/torvalds/linux/commit/c70e1b475f37f07ab7181ad28458666d59aae634" rel="noreferrer" target="_blank">https://github.com/torvalds/linux/commit/c70e1b475f37f07ab7181ad28458666d59aae634</a>.<br>
><br>
> The problem seems to cause NullReferenceException and possibly native<br>
> SIGSEGVs in a variety of places. (I can dump some stacktraces if desired,<br>
> but I suspect that won't be helpful coz the corruption is likely caused<br>
> elsewhere.)<br>
><br>
> To me it seems impossible that reading the tsc in any way could result in<br>
> the nullrefs. So my guess would it a side-effect of the memory barrier. From<br>
> what I understand from the commit, the 'mfence+lfence' changed to 'mfence or<br>
> lfence' (depending on what the cpu supports) and mfrence=lfence+sfence (not<br>
> entirely true, but close), so I have no idea what the heck is going on<br>
> there.<br>
> But if I would venture a guess that somewhere, indirectly, mono unknowingly<br>
> relies on that barrier to be there.<br>
> Theoretically it still means other native apps could experience the same<br>
> problem, but I would've expected reports about that already.<br>
><br>
> My experience in these matters is pretty much non-existent. But dumping<br>
> issues on devs is the least productive way to get them fixed, so I try to<br>
> investigate as far as I can. Especially since it involves an issue that<br>
> could be caused by either mono or the kernel.<br>
><br>
> So my question is: Is there a likely candidate in mono where it uses the tsc<br>
> (possibly for profiling) where the changed barrier could cause this odd<br>
> behavior? And obviously, is there anything in particular I could try to<br>
> narrow this down further?<br>
><br>
> Almost forgot, but I did the bisect using mono 4.0.2.5, but I tested the<br>
> nightly version as well.<br>
><br>
> Thank you for your time.<br>
><br>
> Taloth<br>
><br>
</div></div>> _______________________________________________<br>
> Mono-devel-list mailing list<br>
> <a href="mailto:Mono-devel-list@lists.ximian.com" target="_blank">Mono-devel-list@lists.ximian.com</a><br>
> <a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" rel="noreferrer" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
><br>
<span><font color="#888888"><br>
<br>
<br>
--<br>
Studying for the Turing test<br>
</font></span></blockquote></div><br></div></div>
_______________________________________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com" target="_blank">Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" rel="noreferrer" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
</blockquote></div>
</div></div></blockquote></div><br></div>