[bug #62030] 'Malformed xchar' error, if fork'ed child throws

[Stephan Rudlof]

Follow-up Comment #2, bug #62030 (project gforth):

[comment #1 comment #1:]
> I am not quite sure what's going on, so I assigned it to Bernd.
> 
> The root of the problem seems to be that, if I do
> 
> stdin close-file throw
> 
> gforth 0.7.3 exits,

Not here:
+++
: biz
    fork
    if \ child pid -> parent, or ..
    else \ .. 0 -> child
        \ needed to get normally working terminal (after finishing child)
        stdin close-file throw \ or 'sh stty -icanon' in parent bye...
        cr ." inside child process"
        stdout close-file throw
        history-cold
        1 throw
        bye
    then
;
biz
+++
leads to
+++
biz  ok

inside child process
:9: error 1 
>>>biz<<<
Backtrace:
$7F9F02168D70 throw
+++
(so child has reached printing and '1 throw').


> while 0.7.9_20220120 goes into an endless loop of throwing -77.
> 
> The bug report may point to another problem in the terminal setup and
restoration of Gforth: the reporter apparently is trying to work around the
way this stuff interacts with forking, but it would be better if such
workarounds would not be necessary.


Brainstorming (new to gforth, not knowing low-level details)
------------------------------------------------------------
What happens with low-level stderr of child, if it's throwing (probably used
then)?

May be (very vague) one reason could be lack of synchronizing std io streams:
with mixing them invalid xchars may be the result. But I don't understand, how
low level (C?) stderr could interfere regarding xchars (low level probably
just bytes) between child and parent proc...

However: at higher level I have a solution for (cooperatively) synchronizing
stderr using fcntl locks; but this does not apply to low level output
triggered by throws.

Solutions could be (with much guessing, may totally missing the point):
- fcntl locks of low-level stdout/stderr streams in case of fork'ing;
- no use of xchars, which could become garbage by mixing streams.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62030>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/