bugPSPP - Bugs: bug #20626, PSPP often assert-fails upon...

 
 

bug #20626: PSPP often assert-fails upon control-C

Submitter:  Ben Pfaff <blp>
Submitted:  Mon 30 Jul 2007 04:05:46 AM UTC
   
 
Category:  Other Severity:  5 - Average
Status:  Fixed Assigned to:  None
Open/Closed:  Closed Release:  Post-0.6.0
Effort:  0.00
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 27 Oct 2010 04:45:34 PM UTC, comment #2: 


>This has been fixed (or at least avoided) in a recent commit hasn't it?


Yes, this should be fixed by commit a6903115461 "pspp: Don't attempt fancy clean-up upon receiving a fatal signal."

Ben Pfaff <blp>
Group administrator
Wed 27 Oct 2010 04:00:37 PM UTC, comment #1: 

This has been fixed (or at least avoided) in a recent commit hasn't it?

John Darrington <jmd>
Group administrator
Mon 30 Jul 2007 04:05:46 AM UTC, original submission:  

I'm filing this conversation from pspp-dev as a bug to remind us to revisit it at some point.  It's important and we should fix it.

John Darrington writes:

>I've noticed that occasionally when I hit Ctrl-C, the assertion at
>procedure.c:546 fires.
>
>The problem seems to be that the interrupt handler calls
>destroy_dataset while not in the COMMITTED state.


Ben Pfaff replies:

>We could fix that in the procedure code.  The question is, should
>we?  If we fix the "obvious" problems with asynchronous signals,
>I'm sure that we'll just discover that there are numerous more
>subtle problems with signals, some of which only occur when PSPP
>is compiled with certain optimization flags with some compilers
>on some platforms...
>
>I suspect it's better to not clean up so much on Ctrl+C.  Just
>delete temporary files (if necessary) and exit.  Doing as little
>as possible in a signal handler is Good.


John Darrington continues:

>I suppose that the ideal solution would be to have a signal handler
>which flags a semaphore to indicate that the code should not accept
>more input, stop what it's doing and terminate.  But it's probably an
>overkill ...
>
>Another option:  Introduce a 4th state PROC_TERMINATING.
>destroy_dataset sets this state which it never
>leaves. proc_discard_active_file accepts this state as a valid
>one.


Ben Pfaff replies:

>[...regarding "ideal solution"...]
>In the long run that's something we want to
>do anyway.  I generally consider it "friendly" for a user
>interface to stop whatever it's doing and give me a new command
>prompt if I type Ctrl+C or do the GUI equivalent (e.g. click a
>"stop" button).
>
>I think that this might be cleanly implementable through an
>extension to the taint interface.




Ben Pfaff <blp>
Group administrator

 

(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 jmd (Posted a comment)
  • -email is unavailable- added by blp (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-10-27 blp StatusNone Fixed
        Open/ClosedOpen Closed
    2007-07-30 blp ReleaseNone Post-0.6.0

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code