Simon Gomizelj wrote:
On Thu, 02 Apr 2009 04:56:46 -0400, Georg Wrede <[email protected]> wrote:
With gdb I can either debug a core dump or an actual running process.
For example, with
import std.stdio;
int main()
{
readWrite();
return 8;
}
void readWrite()
{
auto line = readln(); // here it waits, and that's when I debug
// in another window
write("Rivi oli: ", line);
}
I get the following stack trace (it looks the same whether I debug a
core dump or a running instance)
#0 0x00251416 in __kernel_vsyscall ()
#1 0x00591a93 in __read_nocancel () from /lib/libc.so.6
#2 0x00528cee in _IO_new_file_underflow (fp=0x62e420) at fileops.c:598
#3 0x0052c17a in __underflow (fp=0x62e420) at genops.c:361
#4 0x0051e648 in _IO_getdelim (lineptr=0xbf94ec8c, n=0xbf94ec90,
delimiter=10, fp=0x62e420) at iogetdelim.c:79
#5 0x080505bb in _D3std5stdio6readlnFPS3std1c5stdio6_iobufKAawZk ()
#6 0x080504d0 in _D3std5stdio6readlnFPS3std1c5stdio6_iobufwZAya ()
#7 0x0804931a in _D5read29readWriteFZv ()
#8 0x00000000 in ?? ()
This is not perfect, 5..7 are functions written in D, but main is
missing. Then, trying to examine a core dump from something that gets
a segfault, I wrote the following, expecting that I'd get a grandiose
stack trace
$ cat npe.d
import std.stdio;
int main()
{
return foo(3);
}
int foo(int a)
{
return 1 + bar(a - 3);
}
int bar(int b)
{
return 1 + car(b - 3);
}
int car(int c)
{
return 1 + dar(c - 3);
}
int dar(int d)
{
return 1 + * cast(int*) d; // null pointer exception
}
Turns out I got zilch!
#0 0x08049118 in _D3npe3darFiZi ()
#1 0xfffffffa in ?? ()
I have DMD on Fedora 10, and used
dmd -g -debug -v read2.d
to compile. Incidentally, using
dmd -gc -debug -v read2.d
does seem to give the same stack trace.
While I can't explain why gdb and dmd don't seem to work nicely
together, you'd have much better luck using ldc.
Compiling with ldc, this is the backtrace I got when debugging read2.d
on my maching (and is what you're probably looking for):
(gdb) run
Starting program: /data/Code/D/error
[Thread debugging using libthread_db enabled]
[New Thread 0xb7d656c0 (LWP 14104)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7d656c0 (LWP 14104)]
0x080495fe in _D5error3darFiZi (d=-6) at error.d:23
23 return 1 + * cast(int*) d; // null pointer exception
(gdb) backtrace
#0 0x080495fe in _D5error3darFiZi (d=-6) at error.d:23
#1 0x080495e3 in _D5error3carFiZi (c=-3) at error.d:18
#2 0x080495c3 in _D5error3barFiZi (b=0) at error.d:13
#3 0x080495a3 in _D5error3fooFiZi (a=3) at error.d:8
#4 0x0804957d in _Dmain () at error.d:3
#5 0x0804dd0a in _D6dmain24mainUiPPaPPaZi7runMainMFZv ()
#6 0x0804d9c7 in _D6dmain24mainUiPPaPPaZi7tryExecMFDFZvZv ()
#7 0x0804dd4d in _D6dmain24mainUiPPaPPaZi6runAllMFZv ()
#8 0x0804d9c7 in _D6dmain24mainUiPPaPPaZi7tryExecMFDFZvZv ()
#9 0x0804d946 in main ()
Ah, this looks nice. And the file name shows in the function names.
If everyone wasn't telling me it's a licence issue, I'd take it for
granted there's a bug in DMD.
