GDB does not give information about where and how a program attached to gdb failed. WSL

Question

I have searched everywhere for how to fix this and I could not find anything, so I'm sorry if there is already a thread existing on this issue. Also, I'm fairly new to Linux, GDP, and StackOverflow, this is my first post.

First, I am running on Debian GNU/Linux 9 (stretch) with the Windows subsystem for Linux and when I start gdb I get this:

GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
...
This GDB was configured as "x86_64-linux-gnu".
...

Also when I show the configuration I get this:

configure --host=x86_64-linux-gnu --target=x86_64-linux-gnu
          --with-auto-load-dir=$debugdir:$datadir/auto-load
          --with-auto-load-safe-path=$debugdir:$datadir/auto-load
          --with-expat
          --with-gdb-datadir=/usr/share/gdb (relocatable)
          --with-jit-reader-dir=/usr/lib/gdb (relocatable)
          --without-libunwind-ia64
          --with-lzma
          --with-python=/usr (relocatable)
          --without-guile
          --with-separate-debug-dir=/usr/lib/debug (relocatable)
          --with-system-gdbinit=/etc/gdb/gdbinit
          --with-babeltrace

I've created some sample c code to show the issue I have been encountering. I just want to clarify that I know I'm using heaps and I could just as easily use a char buffer for this example, the issue is not about that.

I'll call this sample program test.c

#include <string.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
    char *str = malloc(8);
    char *str2 = malloc(8);

    strcpy(str, argv[1]);
    strcpy(str2, argv[2]);

    printf("This is the end.\n");
    printf("1st: %s\n2nd: %s\n", str, str2);
}

I then compiled it with

gcc -g -o test test.c

And with a quick run, I know that everything works the way it should.

$ ./test AAAAAAAA BBBBBBBB
This is the end.
1st: AAAAAAAA
2nd: BBBBBBBB

When I start the program with no input args, I get a segmentation fault as expected. But when I then try to use gdb to show what exactly happens, I get the following.

$ gdb test
(gdb) run

Program received signal SIGSEGV, Segmentation fault.
__strcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:296
296     ../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S: No such file or directory.

What I expected was to get information about what failed such as the destination address and the source address that were sent as parameters for strcpy, but I just get empty parentheses.

Again I'm relatively new to gdb so I don't know if this is normal or not.

Any help would be great.

EDIT 1

Can you paste the output of (gdb) bt into your question? Your program is stopped in a library function that hasn't had its optional debug information installed on your system, but some other parts of the stack trace may be useful. – Mark Plotnick

(gdb) run
(gdb) bt
#0  __strcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:296
#1  0x00000000080007d5 in main (argc=1, argv=0x7ffffffde308) at test.c:10

(gdb) run AAAAAAAA
(gdb) bt
#0  __strcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:296
#1  0x00000000080007ef in main (argc=2, argv=0x7ffffffde2f8) at test.c:11

Answer 1

What I expected was to get information about what failed such as the destination address and the source address that were sent as parameters for strcpy, but I just get empty parentheses.

Your expectation is incorrect: it order for GDB to give you source and destination address, __strcpy_sse2_unaligned needs to be written in C (or another high-level language), and compiled with debugging info. But it's written in hand-coded assembly, and the writers didn't care to also write debugging info for it (it's quite a bit of extra work, for little benefit).

However, you can still recover the info you seek by executing up command (to get into main) and looking there.

Answer 2

So your backtrace gives you:

(gdb) bt
#0  __strcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:296
#1  0x00000000080007ef in main (argc=2, argv=0x7ffffffde2f8) at test.c:11

which very clearly mentions that it crashes in test.c:11 (that is: line 11 of your test.c file), answering the where part of your question.

and to expand on @employed-russian's answer, to get the why:

(gdb) up
#1  0x0000555555554779 in main (argc=2, argv=0x7fffffffe158) at test.c:11
11      strcpy(str2, argv[2]);
(gdb) print(str2)
$1 = 0x555555756280 ""
(gdb) print argv[2]
$2 = 0x0