bugGNU Common Lisp - Bugs: bug #51939, Troubles with SIGPIPE

 
 

bug #51939: Troubles with SIGPIPE

Submitter:  Martin Saturka <kvutza>
Submitted:  Tue 05 Sep 2017 12:10:21 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 10 Nov 2022 12:57:42 PM UTC, comment #2: 

Greetings, and thanks again for your report!  We are unblocking SIGPIPE in its handler starting in 2.6.13, as we do for other signals, resolving this issue.  All SIGPIPE signals will be handled as received.

Camm Maguire <camm>
Group administrator
Thu 11 Nov 2021 05:27:22 PM UTC, comment #1: 

Greetings, and thanks for your report!  Using current Version_2_6_13pre, (si::allow-signal 13)(si::bye) runs as expected.  Does one need a broken pipe before these calls to trigger what you observe?  If so, can you provide a test case?

Camm Maguire <camm>
Group administrator
Tue 05 Sep 2017 12:10:21 AM UTC, original submission:  

To keep GCL telling me about broken-pipe situations (that is, not ignoring SIGPIPE events), I have to use the respective call for signal allowing:
(si:allow-signal 13)

When it happens that I actually get broken-pipe situation, and when then I do the ''(si:allow-signal 13)'' call that is not matched then by a new broken-pipe situation though, I get (apparently spurious) broken-pipe situations during exiting that GCL session.

Such late broken-pipe event prevents the actual leaving of the GCL session, and I have to call that ''BYE'' function again then.

That late (spurious) broken-pipe event is executed after going into the ''exit(exit_code);'' part at the "BYE" function. See the "o/main.c" file, starting at the line:
''DEFUNO_NEW("BYE",object,fSbye,SI''

If I change the "exit" calling into
''_exit(exit_code);''
then those late broken-pipe events are not executed. Thus it seems to be based on something like atexit/on_exit setting, but I have not found what sets it in.

Notice that I use GCL (mainly) via the Maxima software (in Ubuntu 16.04), and this issue is based on Maxima sessions; I do not have such issues with other lisp interpreters that I tested (they do not need that signal re-enabling though).

A quick/dirty way to go around this is by defining a new variable that says whether we are within leaving the session, and ignoring the broken-pipe calls then.
It can be done e.g. via putting (at top-level) into the ''o/main.c'':
int passing_through_quit = 0;
and then setting it into a nonzero value just before going into the ''exit(exit_code);'' part.
Then at the ''o/usig.c'' file, it can be checked in the ''sigpipe(void)'' function, and only trigger the error processing there if it is zero valued (if the leaving is left anyway, it has to be nullified again though).
I guess that some cleaner way is possible too.

Martin Saturka <kvutza>

 

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

Attach Files:
   
   
Comment:
   

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 camm (Posted a comment)
  • -email is unavailable- added by kvutza (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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-11-10 camm StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code