[erlang-questions] How to track down intermittent segfaults in a threaded NIF
Tue May 29 16:33:56 CEST 2018
Thanks Scott, that sounds very much like what's going on and using
libgmalloc sounds like it's just what I want.
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?
How do the people debug the emulator versions with applications loaded?
On 29/05/2018 13:20, Scott Ribe wrote:
> What's most likely going on is that your NIF is corrupting memory that the scheduler uses. These kinds of corruptions are difficult to track down, because the crash can happen long after the bug.
> You should be running with all memory debugging aids turned on--this can get you a crash closer to the actual bug, if you're lucky maybe even at the bug.
> Scott Ribe
>> On May 29, 2018, at 3:04 AM, Igor Clark <igor.clark@REDACTED> wrote:
>> Thanks Sergej - that's where I got the thread reports I pasted in below, from e.g. 'beam.smp_2018-05-28-212735_Igor-Clarks-iMac.crash'.
>> Each log says the only crashed thread was a scheduler thread, for example "8_scheduler" running "process_main" in the case of the first one below. This is how I tracked down a bunch of errors in my own code, but the only ones that still happen are in the scheduler, according to the Console crash logs.
>> The thing is, it seems really unlikely that a VM running my NIF code would just happen to be crashing in the scheduler rather than my code(!) - so that's what I'm trying to work out, how to find out what's actually going on, given that the log tells me the crashed thread is running "process_main" or 'lists_member_2'.
>> Any suggestions welcome!
>> On 29/05/2018 04:16, Sergej Jurečko wrote:
More information about the erlang-questions