Project

General

Profile

Bug #672

Emacs UI: strange string literal causes crash

Added by John Abbott about 3 years ago. Updated 7 months ago.

Status:
In Progress
Priority:
Low
Assignee:
Category:
EmacsUI
Target version:
Start date:
09 Mar 2015
Due date:
% Done:

20%

Estimated time:
Spent time:

Description

I created a file (CRASH.cocoa5) containing the following:

"^\";

Note that the string is just 1 character long: with ASCII code 28, but Emacs prints it as ^\.

Sending this line to CoCoA-5 (via C-c C-RET) for evaluation causes a crash (after a few seconds).

Reading the file directly into CoCoA-5 seems to work OK (well, it does not crash).

History

#1 Updated by John Abbott about 3 years ago

Other chars which give trouble include those with ASCII code 3, ...
[to be completed]

#2 Updated by John Abbott about 3 years ago

The EmacsUI really seems to do strange things when the input contains unprintable chars. I am guessing that it is the comint function which actually sends the input that is causing the trouble, yet the documentation for comint-send-input says nothing about "mangling".

As a workaround the user can use source and SourceRegion (e.g. via C-c C-f and C-c C-r).

#3 Updated by John Abbott about 3 years ago

  • Description updated (diff)

#4 Updated by John Abbott 7 months ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

I have confirmed that a crash occurs even if you type as input to an interactive CoCoA-5 session the string "\^" where the single character in the string has ASCII code 28.

NOTE the same string literal does strange things when sent to /bin/bash running inside a comint buffer. I have not yet found any useful hints on the internet.

NOTE2 Whatever Emacs does to the string, it should not cause the CoCoA-5 interpreter to crash; so there is a CoCoA-5 bug somewhere.

#5 Updated by John Abbott 7 months ago

  • Assignee set to John Abbott
  • % Done changed from 10 to 20

I have no idea what Emacs does with such an input string. Searching on internet yielded nothing useful.

I have recompiled CoCoAInterpreter without READLINE, and added (temporary) debugging code. Whatever Emacs does, it causes getline to crash; so it is not really a CoCoA-5 problem... but still annoying :-(

Do we just have to close this as an unresolvable issue?

Also available in: Atom PDF