bugGforth - Bugs: bug #63730, The "see" command hangs...


bug #63730: The "see" command hangs forever on a default Ubuntu installation

Submitter:  Jerome Abela <jeromelon>
Submitted:  Mon 30 Jan 2023 02:01:22 PM UTC
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Confirmed
Privacy:  Public Assigned to:  paysan
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup

Mon 30 Jan 2023 10:12:56 PM UTC, comment #3: 

comment #2:

> will you report the bug to Ubuntu, Jerome?

Sure: https://bugs.launchpad.net/ubuntu/+source/gforth/+bug/2004211

Jerome Abela <jeromelon>
Mon 30 Jan 2023 06:58:00 PM UTC, comment #2: 

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)

Anton Ertl <anton>
Group administrator
Mon 30 Jan 2023 03:57:45 PM UTC, comment #1: 

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.

Bernd Paysan <paysan>
Group administrator
Mon 30 Jan 2023 02:01:22 PM UTC, original submission:  

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.

Jerome Abela <jeromelon>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #54291:  dis-gdb.fs added by anton (2KiB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by anton (Updated the item)
  • -email is unavailable- added by paysan (Posted a comment)
  • -email is unavailable- added by jeromelon (Submitted the item)

    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.


    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-01-30 anton Attached File- Added dis-gdb.fs, #54291
        StatusWorks For Me Confirmed
    2023-01-30 paysan StatusNone Works For Me
        Assigned toNone paysan

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code