<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 4, 2014 at 11:01 AM, Steve Vinoski <span dir="ltr"><<a href="mailto:vinoski@ieee.org" target="_blank">vinoski@ieee.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, Nov 4, 2014 at 9:46 AM, Sverker Eriksson <span dir="ltr"><<a href="mailto:sverker.eriksson@ericsson.com" target="_blank">sverker.eriksson@ericsson.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><br>
On 10/31/2014 10:05 PM, Steve Vinoski wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Fri, Oct 31, 2014 at 4:33 PM, Daniel Goertzen <<a href="mailto:daniel.goertzen@gmail.com" target="_blank">daniel.goertzen@gmail.com</a>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I am seeing a segfault that seems to be related to dirty schedulers. I've<br>
reduced the fault to the erlang and C nif module below which executes the<br>
same nif with either the io dirty scheduler, the cpu dirty scheduler, or<br>
the normal erlang scheduler.<br>
<br>
<br>
When I start the emulator and run either dirty nif, I get a segfault. (<br>
see <a href="https://gist.github.com/goertzenator/6237e0200a5f7bf22976" target="_blank">https://gist.github.com/<u></u>goertzenator/<u></u>6237e0200a5f7bf22976</a>)<br>
<br>
</blockquote>
I found it hard to make sense of what's in that gist due to the formatting,<br>
so I took your code and built it myself. When I ran it, it failed in your<br>
NIF load function, but it failed in a way that didn't make sense because<br>
all your function does is return 0. Then I realized none of your C<br>
functions were declared static, which means they are global, and I<br>
suspected your load() function was clashing with some other function of the<br>
same name. I made all your C functions static, rebuilt, and then ran<br>
everything and it seems like it worked:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
c(dlibusb).<br>
</blockquote>
Reading symbols for shared libraries . done<br>
{ok,dlibusb}<br>
2> dlibusb:mytest_cpu().<br>
[ok,ok,ok,ok,ok,ok,ok,ok,ok,<u></u>ok,ok]<br>
3> dlibusb:mytest_io().<br>
[ok,ok,ok,ok,ok,ok,ok,ok,ok,<u></u>ok,ok]<br>
4> dlibusb:mytest_none().<br>
[ok,ok,ok,ok,ok,ok,ok,ok,ok,<u></u>ok,ok]<br>
<br>
--steve<br>
<br>
<br>
</blockquote>
<br></div></div>
Run on debug VM and increase 'cnt' in the NIF mytest to something bigger (like 1000) and this will segfault every time.<br>
<br>
The problem arise when a 0-arity dirty NIF like mytest triggers a GC. The return value from the NIF<br>
is not included in the rootset of the GC (as it should be) and the calling erlang code crashes when it later tries to<br>
read deallocated garbage.<br>
<br>
I did the following fix in init_nif_sched_data() which seems to work.<br>
<br>
ep->fp = indirect_fp;<br>
proc->freason = TRAP;<br>
+ proc->arity = argc;<br>
return THE_NON_VALUE;<br>
}<br>
<br>
<br>
Not sure if that is always the right thing to do.<br>
What do you think, Steve?<br></blockquote><div><br></div></div></div><div>Thanks Sverker, glad you were able to reproduce the problem -- I've tried and tried but have never gotten it to fail. Increasing the array size also makes it reliably crash for me. I'll investigate your proposed fix and will probably add a new test for this.</div></div></div></div></blockquote><div><br></div><div>Thanks again Sverker, this is definitely the right fix. I've submitted a PR for this:</div><div><br></div><div><a href="https://github.com/erlang/otp/pull/531">https://github.com/erlang/otp/pull/531</a></div><div><br></div><div>And Daniel, thanks for finding and reporting this. Sorry I couldn't reproduce it sooner.</div><div><br></div><div>--steve </div></div></div></div>