[erlang-questions] How to track down intermittent segfaults in a threaded NIF

[Igor Clark]

OK, great, thanks Scott! Combining this with Fred's help on running the 
release with custom args, I have this:

> DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib MallocGuardEdges=1 
> MallocStackLogging=1 _build/prod/rel/<my-app>/erts-9.3/bin/erl -boot 
> _build/prod/rel/<my-app>/releases/0.1.0/<my-app> -config 
> _build/prod/rel/<my-app>/releases/0.1.0/sys.config

which runs and gives this:

> beam.smp(62326,0x7fffa52133c0) malloc: stack logs being written into 
> /tmp/stack-logs.62326.1f5a2000.beam.smp.QWSLfS.index

which seems good, the file is present and gets updated.

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?

Or does this only work if I run the entire process through gdb or lldb?

cheers,
i

On 29/05/2018 15:42, Scott Ribe wrote:
>> On May 29, 2018, at 8:33 AM, Igor Clark <igor.clark@REDACTED> wrote:
>>
>>  From what I can tell from its docs, I could either do that in Xcode, or using gdb, right? I have no clue how I'd go about running the BEAM inside Xcode, especially booting my application and NIF code, and I've got a lot to learn about how to connect any of this with rebar3 and releases. Do you run BEAM in Xcode or directly with gdb/lldb?
> Actually, all you have to do is export those environment variables in whatever environment you launch, not just Xcode or gdb.
>
> At launch, they barf some descriptive info to stdout (or stderr?), so if you can figure out where the beam sends that and monitor it, you should see confirmation that they're in effect:
>
>
> SHR-MacBook-Pro:~ sribe$ export MallocStackLogging=1
> SHR-MacBook-Pro:~ sribe$ ls
> ls(32181,0x7fff88acb380) malloc: stack logs being written into /tmp/stack-logs.32181.104a26000.ls.6dB2BT.index
> ls(32181,0x7fff88acb380) malloc: recording malloc and VM allocation stacks to disk using standard recorder
> Applications			Dropbox				Public				eclipse				fsaclctl
> Desktop				Library				Sites				eclipse-workspace		perf_demo
> Desktop Folder			Movies				TheFindByContentFolder		elixir-basics-workshop		pgdata
> Documents			Music				Trash				elixir-fire-brigade-workshop
> Downloads			Pictures			_rvm				elixirconf_workshop
> ls(32181,0x7fff88acb380) malloc: stack logs deleted from /tmp/stack-logs.32181.104a26000.ls.6dB2BT.index
> SHR-MacBook-Pro:~ sribe$
>
>
> Barring that, you could always insert a deliberate overrun in your NIF's initialization and check that it immediately crashes with an access violation.
>
> --
> Scott Ribe
> scott_ribe@REDACTED
> https://www.linkedin.com/in/scottribe/
>
>
>
>