Add a New Comment (Rich Markup)
comment #2:
> will you report the bug to Ubuntu, Jerome?
Sure: https://bugs.launchpad.net/ubuntu/+source/gforth/+bug/2004211
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)
This is (mostly) fixed in the current development Gforth by providing native (integrated) disassemblers for most current popular platforms such as amd64 and arm64 (so I put this under “works for me”, because I use the development branch, and the 1.0 release isn't far away). Furthermore, when you set yama/ptrace_scope to 1 in the development system, gdb failing is also detected, and then it reverts to dumping the code, so it does not hang anymore. I think the only further improvement possible is to fix the warning from gdb about obsolete commands. Backports to Gforth 0.7.3… not from us.
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.
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Only logged-in users can vote.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 4 latest changes.
Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.11