bugGforth - Bugs: bug #26261, Seeing assembly code on Mac OS X...


bug #26261: Seeing assembly code on Mac OS X robs me of my identity

Submitted by:  John T. Wodder II <minimiscience>
Submitted on:  Tue 21 Apr 2009 01:49:28 AM UTC  
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  Bernd Paysan <paysan>
Open/Closed:  Closed

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Mon 23 Nov 2015 09:28:49 PM UTC, comment #7:

On newer versions of Mac OS X, it is not easily possible to launch gdb as normal user, so disasm-gdb will fail. As you have too jump through various hoops to get gdb to run as normal user, and then it still fails when launched from Gforth on Mac OS X, I suggest you wait until Anton has completed his binutil library based disassembler.

Bernd Paysan <paysan>
Project AdministratorIn charge of this item.
Mon 23 Nov 2015 02:52:09 AM UTC, comment #6:

I can confirm ksnieck's problem on both my 2015 macbook pro and my 2011.
The 2015 is running 10.10.4 and the 2011 is running 10.8....

Ben K Steele <drbenkman>
Sat 01 Aug 2015 04:08:38 AM UTC, comment #5:

I'm experiencing something similar to this bug. When I use "see" to print a built-in word ( see +, for example ) that prints out assembly (like the original post describes), gforth prints the assembly output, but for me it then hangs until I kill it with "kill -9 pid".

I'm using 64-bit gforth, compiled with homebrew, on Mac OS X 10.10.4, uname -a : Darwin x.local 14.4.0 Darwin Kernel Version 14.4.0: Thu May 28 11:35:04 PDT 2015; root:xnu-2782.30.5~1/RELEASE_X86_64 x86_64

Kurt Snieckus <ksnieck>
Fri 02 Apr 2010 07:31:52 PM UTC, comment #4:

The last round of updates on Mac OS X seem to fix this problem - while I could reproduce it before, it's now gone. This was a genuine Mac OS X bug, and should now be fixed.

Bernd Paysan <paysan>
Project AdministratorIn charge of this item.
Wed 22 Apr 2009 07:52:24 AM UTC, comment #3:

Thanks for the feedback. Your pointer to launchd may help Bernd to
reproduce the problem.

It's not surprising that you don't see this with the 32-bit version
because by default it does not use DISASM-GDB. My guess is that you
will see the same effect if you do:

' disasm-gdb is discode
see +

Anton Ertl <anton>
Project Administrator
Wed 22 Apr 2009 01:49:59 AM UTC, comment #2:

Looking into this more, I've found that using SEE on built-in commands somehow causes the "launchd" program to exit due to a segmentation fault, with this near the top of the crash report:

This explains the inability to open applications. Unfortunately, I still have no idea exactly why this is happening. I have found that this problem only occurs when Gforth is configured to be 64-bit; invoking "configure" with no options leads to the creation of an executable without this problem, albeit slightly slower and with smaller numbers. The only possible cause that I can definitively rule out is Leopard's quarantining of downloaded files; when I realized that the source & executable were quarantined, I removed the extended attributes, only for the problem to persist.

I have no idea what differences could cause the problem to not occur for you, though if you ask for any specific hardware or software details of my computer, I can most likely give them to you.

John T. Wodder II <minimiscience>
Tue 21 Apr 2009 05:07:17 PM UTC, comment #1:

Bernd Paysan has tried this on MacOS X 10.5.6, and could not reproduce
the problem. Maybe you can follow the suggestions I made in my mail,
and find out more information about the issue, which we can then use
somewhere in the installation.

To have this stuff in the bug tracker and in case my mail has not
reached you, here I reproduce my text:

That means you are using DISASM-GDB for SEEing primitives. This word
invokes a number of shell commands (in particular: type mktemp echo
gdb rm); my guess is that one of these commands (at least as invoked
by Gforth) has the side effect you observe.

Since you still have the same uid (and are in the same groups), you
should still have the same permissions, and tools should be able to
look up your user name in /etc/passwd (if they look there) in the
traditional Unix security model. I guess what you are seeing is an
effect of some additional security framework, but I am not familiar
with that (whatever it is), so I cannot really help you there.

The following are just educated guesses: I have read about SELinux
that someone needs to finetune the policies for the various
applications. By default they are restrictive, and if you notice that
it is forbidding something that's ok, you should allow that. My guess
is that gdb's use of ptrace() to attach to the gforth process looks
suspicious to your security framework and it then disallows some
things. Maybe you find something about this in the logs of your
security framework.

Anton Ertl <anton>
Project Administrator
Tue 21 Apr 2009 01:49:28 AM UTC, original submission:

I just compiled & installed Gforth 0.7.0 on Mac OS X 10.5.6 (Intel MacBook), and I've encountered a strange problem: whenever I use "see" to print out a built-in command (i.e., one defined in assembly/machine code rather than as a composite of simpler Forth commands), I afterwards seem to somehow lose my username and some basic permissions. Everything else with Gforth seems to be fine; as far as I can tell, this only happens when "see"ing built-in commands.

I've tried this at least three times, and the behavior is always the same. Prior to using "see" in this way, the output from "id" is:
and "whoami" displays my username. After using "see", even in a separate Terminal window, the output from "id" changes to:
(note the lack of my username), and "whoami" just prints out "501". In addition, I am no longer able to empty the Trash (as I apparently lack permissions that I should have), and attempting to open any new applications results in an error. There may be more side-effects, but I have no desire to seek them out. This username-less state can be easily resolved by logging out & then logging back in again, but it's still quite inconvenient and a bit disturbing.

For reference, I invoked "configure" with:
I'm quite sure that my computer qualifies for the performance boost this configuration gives; for comparison, the output from "uname -a" is:
My only other deviation from the basic installation instructions was to use "sudo make install" instead of "make install" for permissions reasons.

John T. Wodder II <minimiscience>


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

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


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

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    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.

    Date Changed by Updated Field Previous Value => Replaced by
    Sat 19 Dec 2015 09:58:00 PM UTC paysan Open/ClosedOpen => Closed
    Fri 02 Apr 2010 07:31:52 PM UTC paysan StatusWorks For Me => Fixed
    Tue 21 Apr 2009 05:07:17 PM UTC anton StatusNone => Works For Me
        Assigned toNone => paysan

    Back to the top

    Powered by Savane 3.3