<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><br></div><div>Taloth</div><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>