Jump to page: 1 2
Thread overview
How to debug D on Linux
3 days ago
Roguish
3 days ago
Roguish
3 days ago
Roguish
3 days ago
drug
3 days ago
drug
3 days ago
Roguish
3 days ago
Adam D. Ruppe
2 days ago
Roguish
3 days ago
evilrat
2 days ago
Roguish
2 days ago
Roguish
2 days ago
Daniel Kozak
3 days ago
user1234
2 days ago
Roguish
3 days ago
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?
3 days ago
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?
3 days ago
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) ?
3 days ago
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
3 days ago
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.
3 days ago
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.
3 days ago
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.
3 days ago
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.
3 days ago
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.
3 days ago
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.

« First   ‹ Prev
1 2