<div><div><div dir="auto">Can you give it a try with <span style="white-space:pre-wrap;background-color:rgb(255,255,255)">"+Mea min" in erl options? This should make Erlang fall back to malloc for all allocators, hopefully making guard malloc more effective.</span></div><div dir="auto"><br></div><div dir="auto">Dominic</div><div><br><div class="gmail_quote"><div>2018年5月30日(水) 5:15 Igor Clark <<a href="mailto:igor.clark@gmail.com" target="_blank">igor.clark@gmail.com</a>>:<br></div></div></div></div></div><div><div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">OK. Thanks very much Scott. I've got all this working using both those <br>
extra options, and it does seem to make the NIF crash a lot sooner than <br>
previously, which is great. But I'm still only seeing "process_main" in <br>
the crashed thread, so I'm not much closer to knowing where the illegal <br>
access is. I wonder if it's in lots of places because of what I'm doing <br>
with the callback and the thread. I hope not.<br>
<br>
I'll do some more digging, and tomorrow I'll try out a debug emulator <br>
build as well.<br>
<br>
Thanks very much for helping me get this far!<br>
<br>
On 29/05/2018 16:31, Scott Ribe wrote:<br>
>> On May 29, 2018, at 9:16 AM, Igor Clark <<a href="mailto:igor.clark@gmail.com" target="_blank">igor.clark@gmail.com</a>> wrote:<br>
>><br>
>> So, do I have this right: the point of the Guard Malloc is to make the crash happen at the time of allocation, rather than delayed until something trying to access it triggers the segfault; so if I get a crash while running like this, I should be able to just check in the Console debug log, and the stack trace should show where the bug actually is?<br>
> At the time of the illegal access, not the allocation. Yes, that's the point, you get a stack trace showing you illegal access.<br>
><br>
> However, the BEAM allocator will reduce its effectiveness. When you malloc in your C code, you get a block set up such that accessing just past it (or potentially before it) will cause an immediate crash. When you free it, it's then set up such that accessing will cause an immediate crash. But if you use Erlang's allocation routines, Erlang may malloc a bigger block with those protections, then hand out multiple suballocations, and access beyond the end of one of those can simply corrupt the next one without crashing at that point.<br>
><br>
> You should also be using MallocScribble & MallocPreScribble.<br>
><br>
><br>
><br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div></div></div></div>