pforth crashes with exit status 139. We confirmed the crash by
re-running it in a fresh debian unstable installation.

The attachment [1] contains a testcase (under ./crash) crashing the
program. It ensures that you can easily reproduce the bug. Additionally,
under ./crash_info/, we include more information about the crash such as
a core dump, the dmesg generated by the crash, and its output.

Regards,
The Mayhem Team (Alexandre Rebert, Thanassis Avgerinos, Sang Kil Cha, David Brumley, Manuel Egele)
Cylab, Carnegie Mellon University

[1] http://www.forallsecure.com/bug-reports/1952a55a7e96c3431a32e1eee7b115b24a50e203/full_report

The program passed to pforth starts with @ with no items on the stack,
while @ requires one.
This invokes ambiguous behaviour so pforth is fully entitled to crash.
(DPANS 2.1)
So this bug report must be rejected and closed.
P.S. This bug report reflects an appalling lack of understanding of
Forth.

Groetjes Albert

I am the author of pForth.

I cannot access the attachment from the URL in message #5. But in comment
#10, Albert says the program starts with a @ command. I agree with Albert
that pForth is expected to randomly crash in that case. Such a program
essentially grabs an undefined address from an underflowing stack and tries
to read from that address. That may or may not crash, depending on the
address.

PForth is a typical programming language that allows a developer to write
incorrect code that can crash.

I believe this bug should be closed as "Working As Intended".

tags 716143 +wontfix
thanks

The upstream author of pforth has weighed in and believes that crashing in
this way means that pforth is working as intended.

I'll leave the bug open so it isn't duplicated in the future, but mark it
wontfix as I don't intend to change anything because of it.

Bdale