CODEWITHSUNDEEP
cinputgdb
j0j0j0
j0j0j0

Reputation: 97

how to use a GDB input file for multiple input

EDIT: GDB was not the issue. Bugs in my code created the behaviour.

I am wondering how GDB's input works.

For example I created the following small c program:

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

int main(){

    setbuf(stdout,NULL);

    printf("first:\n");

    char *inp;
    size_t k = 0;
    getline(&inp, &k, stdin);
    printf("%s",inp);
    free(inp);

    // read buffer overflow
    printf("second:\n");

    char buf[0x101];
    read(fileno(stdin),buf,0x100);
    printf("%s",buf);

    printf("finished\n");
}

It reads two times a string from stdin and prints the echo of it.

To automate this reading I created following python code:

python3 -c 'import sys,time; l1 = b"aaaa\n"; l2 = b"bbbb\n"; sys.stdout.buffer.write(l1); sys.stdout.buffer.flush(); time.sleep(1); sys.stdout.buffer.write(l2); sys.stdout.buffer.flush();'

Running the c programm works fine. Running the c program with the python input runs fine, too:

python-snippet-above | ./c-program

Running gdb without an input file, typing the strings when requested, seems also fine.

But when it comes to using an inputfile in gdb, I am afraid I am using the debugger wrongly. Through tutorials and stackoverflow posts I know that gdb can take input via file.

So I tried:

& python-snippet > in
& gdb ./c-program
run < in

I expected that gdb would use for the first read the first line of the file in and for the second read the second line of in.

in looks like (due to the python code):

aaaa
bbbb

But instead gdb prints:

(gdb) r < in
Starting program: /home/user/tmp/stackoverflow/test < in
first:
aaaa
second:
finished
[Inferior 1 (process 24635) exited with code 011]

Observing the variable buf after read(fileno(stdin),buf,0x100) shows me:

(gdb) print buf
$1 = 0x0

So i assume that my second input (bbbb) gets lost. How can I use multiple input inside gdb?

Thanks for reading :)

Upvotes: 1

Views: 2277

Answers (1)

Employed Russian
Employed Russian

Reputation: 213799

I am wondering how GDB's input works.

Your problem doesn't appear to have anything to with GDB, and everything to do with bugs in your program itself.

First, if you run the program outside of GDB in the same way, namely:

./a.out < in

you should see the same behavior that you see in GDB. Here is what I see:

./a.out < in
first:
aaaa
second:
p ��finished

So what are the bugs?

The first one: from "man getline"

getline() reads an entire line from stream, storing the address
of the buffer containing the text into *lineptr.

If *lineptr is NULL, then getline() will allocate a buffer
for storing the line, which should be freed by the user program.

You did not set inp to NULL, nor to an allocated buffer. If inp didn't happen to be NULL, you would have gotten heap corruption.

Second bug: you don't check return value from read. If you did, you'd discover that it returns 0, and therefore your printf("%s",buf); prints uninitialized values (which are visible in my terminal as ��).

Third bug: you are expecting read to return the second line. But you used getline on stdin before, and when reading from a file, stdin will use full buffering. Since your input is small, the first getline tries to read BUFSIZ worth of data, and reads (buffers) all of it. A subsequent read (naturally) returns 0 since you've already reached end of file.

You have setbuf(stdout,NULL);. Did you mean to disable buffering on stdin instead?

Fourth bug: read does not NUL-terminate the string, you have to do that yourself, before you can call printf("%s", ...) on it.

With the bugs corrected, I get expected:

first:
aaaa
second:
bbbb
finished

Upvotes: 2

Related Questions