occivink / kakoune-gdb

gdb integration plugin
The Unlicense
53 stars 8 forks source link

Halting on gdb-session-new #16

Open gustavo-hms opened 4 years ago

gustavo-hms commented 4 years ago

Hi, @occivink ! Thanks for this project.

I'm unable to use it thought. Running gdb-session-new with or without parameters leave me with the message

waiting for shell command to finish

in the status line. If I then press <c-c>, the tmux pane with a gdb shell opens, but Kakoune doesn't connect to it. Running echo %opt{gdb_started} prints false.

I'm running Kakoune from master on FreeBSD. Gdb is 8.3.1. Perl is 5.30.1 and socat is 1.7.3.4.

The contents of the *debug* buffer:

[gdb][kak] gdb-cmd -gdb-exit
shell stderr: <<<
mktemp: illegal option -- -
usage: mktemp [-d] [-q] [-t prefix] [-u] template ...
       mktemp [-d] [-q] [-u] -t prefix
mkfifo: /input_pipe: Permission denied
>>>
[gdb][kak] gdb-handle-perl-exited

Please let me know if you need further information.

Thanks again.

gustavo-hms commented 4 years ago

It seems that FreeBSD's mktemp command doesn't have a --tmpdir option. If I understand the man page correctly, it should work as expected without that option:

     If the -t prefix option is given, mktemp will generate a template string
     based on the prefix and the TMPDIR environment variable if set.  The
     default location if TMPDIR is not set is /tmp.  Care should be taken to
     ensure that it is appropriate to use an environment variable potentially
     supplied by the user.

     If no arguments are passed or if only the -d flag is passed mktemp
     behaves as if -t tmp was supplied.
occivink commented 4 years ago

Mh yes the same issue occured there https://github.com/occivink/kakoune-sudo-write/pull/4, let me fix that up. Is that the only issue?

gustavo-hms commented 4 years ago

Unfortunately, no.

I've replaced line 119 with

    export tmpdir=$(mktemp -d gdb_kak_XXX)

But it's still freezing. And, this time, debug messages are less useful:

[dgb][kak] gdb-cmd -gdb-exit

After pressing <c-c>, echo %opt{gdb_started} prints true this time. But, if I try to set a breakpoint:

[gdb][kak] gdb-handle-perl-exited gdb_kak_gev

and %opt{gdb_started} turns false.

occivink commented 4 years ago

Does setsid (the program) exist on OpenBSD?

gustavo-hms commented 4 years ago

It doesn't.

I'm not familiar with setsid, but it seems you can use daemon in FreeBSD to achieve the same results, depending on your usage of course.

Unfortunately, I can't go further, since I'm not familiar with this API.

I tried to simply replace setsid with daemon to see what happens. It kind of works. I need to test it more to see if something is really broken or it's just me doing things the wrong way.

The only real error message that's printed is

[kakoune-gdb] Internal error handling this output: ^done,frame={level="0",addr="0x0000000801575a18",func="_accept",from="/lib/libc.so.7",arch="i386:x86-64"}

as soon as gdb starts.

gustavo-hms commented 4 years ago

OK. It seems it's working.

Replacing line 119 with

export tmpdir=$(mktemp -d gdb_kak_XXX)

and the setsid program with the daemon program does the job on FreeBSD and, probably, also on macOS, although I didn't test it in the latter.

occivink commented 4 years ago

technically setsid/daemon is not strictly necessary, but if you don't use it then pressing <c-c> in kakoune will kill the whole gdb process tree which is pretty annoying.

Elijah-29 commented 1 year ago

OK. It seems it's working.

Replacing line 119 with

export tmpdir=$(mktemp -d gdb_kak_XXX)

and the setsid program with the daemon program does the job on FreeBSD and, probably, also on macOS, although I didn't test it in the latter.

I have the same issue in FreeBSD-13.2. I changed the two position, It now have gdb started but kak does not connect to gdb. When I enter gdb-session-new in kakoune, kakoune still show waiting for shell command to finish, and if i control-c, a gdb pane show up, but kakoune not connect to it.

occivink commented 1 year ago

Could you check if socat appears as a child process of kakoune as it's hanging? Maybe you could also try to replace the braces at lines 149 and 159 (https://github.com/occivink/kakoune-gdb/blob/master/gdb.kak#L149) with ( and ) instead? @Screwtapello reminded me recently that a bug on some BSD variant might cause the brace construct to not actually run in the background

Elijah-29 commented 1 year ago
Screen Shot 2023-10-12 at 16 43 02

This is what I get, after I changed the two position + the braces.

edit: kak still halt and if I control-c, gdb pane show up and correct load my exectuable file:

Screen Shot 2023-10-12 at 16 51 45
occivink commented 1 year ago

Ok so possibly an issue with the call to socat. Could you check if calling socat 'pty,wait-slave,link=/tmp/test-pty,pty-interval=0.1' STDIO,nonblock=1 works, and if it creates a pty object in /tmp/test-pty ?

Elijah-29 commented 1 year ago

what I get :

Screen Shot 2023-10-12 at 21 05 40
occivink commented 1 year ago

Could you please try the following:

If that still doesn't work, please upload the diff of your gdb.kak so that I understand the extent of the local changes you have.

Elijah-29 commented 1 year ago

25 mktemp should be fix.

Elijah-29 commented 1 year ago

kakoune-gdb work on FreeBSD now, but there still a litter bug(maybe).

When I quit gdb, on linux kak clear the session correct but not on FreeBSD. And I think the wrong is because of this line https://github.com/occivink/kakoune-gdb/blob/2cbf73ac9b2f13cf20417efe5ce27aab08bc7beb/gdb.kak#L154C12-L154C12

Beacuse when I quit gdb. I found pty file in /tmp/gdb_kakXXX is disappeared but fifo in /tmp/gdb_kakXXX/input_pipo still there. so the line https://github.com/occivink/kakoune-gdb/blob/2cbf73ac9b2f13cf20417efe5ce27aab08bc7beb/gdb.kak#L156 (and after that line) have not run.

I think that is why, when I quit gdb, FreeBSD and Linux debug buffer give me different thing (look at the last line)

Screen Shot 2023-10-13 at 18 45 32

I found the bug because on freebsd after I quit gdb, the left Line flags have not disappear like linux.

Screen Shot 2023-10-13 at 22 03 32

I have do something, but I cannot solve this problem