Does not work for me.  Yes, there is the workaround of using the Gforth disassemblers, but sometimes I want to use disasm-gdb; e.g., for instructions that the Gforth disassemblers don't support or that they disassemble in funny ways.

One can see it as a bug in Ubuntu, but the Ubuntu people probably consider it a feature.  And I doubt that they will disable this feature for Gforth, or are able to produce a workaround for their breakage.

So how do we deal with it? I found a workaround (attached) that works with Ubuntu 22.04, but failed when I tried it on Debian 7 (due to differences between gdb versions).  Well, I guess the 22.04 workaround is good enough for attaching to a bug report to Ubuntu, so they can apply it to their release; will you report the bug to Ubuntu, Jerome?

If we wanted to produce a 0.7.4, I would have to work out something that works with older gdb versions.  Tinkering at it for an hour produced nothing workable, but it's just a matter of putting in more work (but is it worth it?).

I guess I will do something better for 1.0.


(file #54291)

Steps to reproduce:
  * start gforth
  * run "see +"
The output is:
  Code + 
And then it hangs for ever.

This is due to the default value for /proc/sys/kernel/yama/ptrace_scope (1), which only allows a process to trace its children, so the attach fails, so the gdb script fails, so gdb never exits, and gforth waits forever for gdb to exit.

It would be great to handle this case gracefully, for example by detecting this case, and showing an error message instead of hanging.