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

 
 

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

Submitted by:  Ben Pfaff <blp>
Submitted on:  Mon 30 Jul 2007 04:05:46 AM UTC  
 
Category: OtherSeverity: 5 - Average
Status: FixedAssigned to: None
Open/Closed: ClosedRelease: Post-0.6.0
Effort: 0.00

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project 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>
Project 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>
Project Administrator

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jmd (Posted a comment)
  • -unavailable- added by blp (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 27 Oct 2010 04:45:34 PM UTCblpStatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Mon 30 Jul 2007 04:06:16 AM UTCblpReleaseNone=>Post-0.6.0

    Back to the top


    Powered by Savane 3.1-cleanup1