Thread overview | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
January 13, 2021 How to debug D on Linux | ||||
---|---|---|---|---|
| ||||
How to debug D? My little trial app gives a segmentation fault. Probably a null pointer somewhere, which I could find simply by reading my code. But I'm puzzled that the program outputs very little helpful info when it crashes, even though I've compiled with all the debug options I could find in the docs: -g -gs -gf -debug -d-debug Still all I get at runtime is Segmentation fault (core dumped) Surely it should be possible to get at least a stack trace? |
January 13, 2021 Re: How to debug D on Linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Roguish | On Wednesday, 13 January 2021 at 13:22:01 UTC, Roguish wrote:
> How to debug D? be possible to get at least a stack trace?
I've discovered that GDB works with the binary generated by the D compiler, so that's great.
Anything else I need to know when debugging on Linux, without an IDE?
|
January 13, 2021 Re: How to debug D on Linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Roguish | On Wednesday, 13 January 2021 at 13:30:48 UTC, Roguish wrote:
> Anything else I need to know when debugging on Linux, without an IDE?
One specific question I have is: what's the difference between -g and -debug and -d-debug?
Also, what does it mean to "always emit a stackframe" (compiler option -gs) ?
|
January 13, 2021 Re: How to debug D on Linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Roguish | On 1/13/21 4:47 PM, Roguish wrote: > On Wednesday, 13 January 2021 at 13:30:48 UTC, Roguish wrote: >> Anything else I need to know when debugging on Linux, without an IDE? > > One specific question I have is: what's the difference between -g and -debug and -d-debug? > > Also, what does it mean to "always emit a stackframe" (compiler option -gs) ? https://stackoverflow.com/questions/17392200/debugging-dmd-generate-program-through-gdb |
January 13, 2021 Re: How to debug D on Linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Roguish | On 1/13/21 4:47 PM, Roguish wrote:
>
> Also, what does it mean to "always emit a stackframe" (compiler option -gs) ?
Short answer - sometimes the compiler does not emit a stackframe (due to optimization for example). In general if you are able to debug your binary by gdb then you don't need to worry this flag.
I skip long answer, sorry :-) But you can google about stack frame.
|
January 13, 2021 Re: How to debug D on Linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Roguish | On Wednesday, 13 January 2021 at 13:47:55 UTC, Roguish wrote: > One specific question I have is: what's the difference between -g and -debug and -d-debug? -debug enables the `debug` keyword inside the D code itself. This lets you bypass other rules temporarily. For example void foo() pure { writeln("called foo"); } Normally, that wouldn't compile, since writeln is not pure. But if you do void foo() pure { debug writeln("called foo"); } It is allowed. Without the `-debug` switch, that line is just ignored, it is not compiled. With the `-debug` switch, that line is allowed - and it bypasses the pure restriction. It does NOT do anything related to running D in debuggers like gdb, it just enables code guarded by that debug keyword. > -g -g is what compiles in the information gdb uses. This info is used to print function names in stack traces, make breakpoints by file and line number, etc. You can use -g and -debug together or independently or whatever depending on what exactly you want to do. Now, some general tips on using D with gdb: * Segfaults should be run inside the debugger to get the stack trace. If your program did "Segmentation fault (core dumped)", you can fire up gdb after the fact on it. Check that directory for a .core file and then run `gdb program that.core` to inspect it. * Running a program in gdb may sometimes say "program received SIGUSR1" and pause. The commands handle SIGUSR1 noprint handle SIGUSR2 noprint will skip this. SIGUSR1/2 are used by the GC when doing collections so you probably don't care about it. You can put those commands i your ~/.gdbinit to run every time. * Running `gdb --args ./yourprogram --DRT-trapExceptions=0` will break on any uncaught exception so you can inspect that stuff. Super useful if you get one of those. |
January 13, 2021 Re: How to debug D on Linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Roguish | if you are looking for back trace someone recently posted a hint for linux where there is no back trace by default is to import core.sys.linux.backtrace or something that has back trace info and using it in exception handler for runtime to print the stack trace. https://dlang.org/phobos/core_runtime.html#.defaultTraceHandler On Wednesday, 13 January 2021 at 13:47:55 UTC, Roguish wrote: > > One specific question I have is: what's the difference between -g and -debug and -d-debug? no idea what is -d-debug, but -g will emit debug info for debugger, and -debug will turn on certain features such as contracts and asserts even in release builds. |
January 13, 2021 Re: How to debug D on Linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Roguish | On Wednesday, 13 January 2021 at 13:47:55 UTC, Roguish wrote:
> On Wednesday, 13 January 2021 at 13:30:48 UTC, Roguish wrote:
>> Anything else I need to know when debugging on Linux, without an IDE?
>
> One specific question I have is: what's the difference between -g and -debug and -d-debug?
From LDC (ldc specific):
--d-debug[=<level/idents>] - Compile in debug code >= <level> or identified by <idents>
--d-version=<level/idents> - Compile in version code >= <level> or identified by <idents>
From dmd:
-debug compile in debug code
-debug=<level> compile in debug code <= level
-debug=<ident> compile in debug code identified by ident
-version=<level> compile in version code >= level
-version=<ident> compile in version code identified by ident
Same thing.
|
January 13, 2021 Re: How to debug D on Linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to Roguish | On Wednesday, 13 January 2021 at 13:47:55 UTC, Roguish wrote:
> On Wednesday, 13 January 2021 at 13:30:48 UTC, Roguish wrote:
>> Anything else I need to know when debugging on Linux, without an IDE?
>
> One specific question I have is: what's the difference between -g and -debug and -d-debug?
>
> Also, what does it mean to "always emit a stackframe" (compiler option -gs) ?
-g : generate dwarf info, the debug info, the most important
-debug : compiles the debug statements, e.g debug logging. not so important, this
is a conditional compilation feature.
-gs : always emit a prelude/prologue. but dmd pretty much always do that even
when not required (sigh).
You really mostly only requires -g. Then you have to learn gdb.
A few basis to get started, a session for a segfault is often like
$ gdb ./myapp
$ run
and when it crashes, note the source position, additionally
$ bt
$ p somevar
$ p some.more.complex.expression
may already give interesting infos. If not, during a second session you will rather put breakpoints to see what happens before the access violation and step from that breakpoint to the code that accesses unowned memory.
$ gdb ./myapp
$ break <somefile>.d <linenum>
$ run
and then step by step, each time it pauses you inspect the interesting stuff.
Note that I may be wrong on the syntax of the commands as I always use an IDE GUI.
|
January 13, 2021 Re: How to debug D on Linux | ||||
---|---|---|---|---|
| ||||
Posted in reply to drug | On Wednesday, 13 January 2021 at 14:13:07 UTC, drug wrote:
> Short answer - sometimes the compiler does not emit a stackframe (due to optimization for example).
OK, so -gs prevents a certain optimization that would make debugging harder in certain situations. Thanks for clearing that up.
|
Copyright © 1999-2021 by the D Language Foundation