how to troubleshoot a crash?

I suppose I should actually try to answer the question being asked. :)

I don't know if there's a good write-up on troubleshooting wireshark crashes in particular, but I'll try to give the 30-second simplifies overview. Ultimately though, this requires some basic understanding of programming, and the C language in particular, because you'd have to look into the source code itself.

Basically what I do is start with the exception type and crash dump stack trace (or sometimes called a backtrace).

This is the exception type:

Exception Type:  EXC_BREAKPOINT (SIGTRAP)

That tells you a SIGTRAP was issued, either on purpose or due to an exception. In this case it's not that helpful, because you could guess that from the stack trace... but sometimes it is useful, for divide by zero, memory errors, etc.

This is the stack trace:

0   libglib-2.0.0.dylib             0x000000010811005b g_logv + 1371
1   libglib-2.0.0.dylib             0x00000001081102dd g_log + 381
2   libwireshark.0.dylib            0x00000001035d7289 proto_register_field_init + 57
3   libwireshark.0.dylib            0x00000001035d7fd1 proto_register_field_array + 161
4   libwireshark.0.dylib            0x00000001040feb33 Proto_commit + 579
5   libwireshark.0.dylib            0x0000000104114652 wslua_init + 1058
6   org.wireshark.Wireshark         0x0000000103199c17 main + 1879
7   org.wireshark.Wireshark         0x0000000103132cb4 start + 52

What a stack trace tells you is the last set of functions, in reverse order, that were called and are in the call stack. I.e., it stopped in g_logv(), which it got to from within g_log(), which it got to from within proto_register_field_init(), etc. (note that it's not all functions the program executed, just the ones still on the stack, meaning the ones to still be returned from and popped from the stack)

Those are literally the function names from within the source code - if the program was compiled with full debug symbols, you'd even see source code filenames and such. The hex numbers to the left of the function names are the program counter addresses, which won't be helpful.

The names on the left tell you which program/library it's executing for that function. "libglib-2.0.0.dylib" is the Glib library, while "libwireshark.0.dylib" is the core Wireshark library, and "org.wireshark.Wireshark" is the Wireshark application itself (or really a symbolic link to it). The "dylib" extension tells you it's a dynamic library in Mac (similar to a "DLL" dynamic linked library in Windows, and a "so" shared object in Linux).

So using the stack trace you gave, I can tell the crash happens during the internal registering of Lua fields. Because I know that's what Proto_commit() does, when it is calling proto_register_field_array().

Technically the "crash" occurs in g_logv() in the sense of that's the function that caused the SIGTRAP, but that's really just a Glib function that was called by g_log() which is another Glib function, and that one was apparently called by proto_register_field_init(). I say "apparently", because it was something that is really a macro or inlined, because there is no direct call to g_log() inside proto_register_field_init().

With full debug symbols it's a lot easier to figure out exactly where it happened, because you'd get the source code line numbers too. But ultimately it's not really telling you why it crashed, in the sense of what was the root cause - it's more telling you how it crashed.

My guess is it's actually "g_error()" being called, on purpose, inside proto_register_field_init()... because it encountered something that is a programming error and needs to be fixed. g_error() is a macro, not a function, so it won't show up in the stack trace. (a macro is a pre-processor directive during compilation) In fact proto_register_field_init() doesn't even directly call g_error(), so it could be being called via one of the other macros used in proto_register_field_init(), or via some function that the compiler chose to inline. (by "inline" I mean it didn't keep the function separate, but instead moved its logic into the calling function, to increase performance)

The fact that it crashes is really a C-code programming error, not a Lua one - the Wireshark Lua API C-code tries to prevent actual crashes for bad Lua scripts, by doing verification checking before calling the rest of the C-code.

So it's probably some incorrect Lua ProtoField in the script, that isn't being properly verified by the C-code. Of course ultimately the Lua script itself is probably wrong too, or maybe it's a fine Lua script and there's some bug in the Wirehark Lua API code. (it could just be a bug - that field registration code was changed recently... although more recently than your version I think... 1.11.3-rc1-1864 isn't very recent)

Generally you're not expected to debug a crash yourself - I mean it's great if you can, but I don't think it's a big deal if you don't. Just submit a new bug in bugs.wireshark.org, with the info you provided above.

Usually it helps to have the capture file that caused the crash, but in this case it's not a capture file - it's something wrong happening inside Wireshark during startup, when it's trying to internally register the ProtoFields from your Lua script. (After all the Lua scripts are loaded and executed, Wireshark internally registers the protocols and fields created by the scripts)

It may well be something incorrect in your Lua script, but it still shouldn't crash. It should just generate an error and continue; preferably it should fail while loading your Lua script, before even trying to register the field(s) internally.

So to help debug this you need to attach the Lua script itself to the bug ticket - or some minimal version of the script with just enough to cause the crash. Like even just the portion of the script that creates ProtoFields will probably be enough to figure it out - you don't need to include the dissector function or anything else really.