bug-gnu-pspp
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ben Pfaff
Subject: PSPP-BUG: [bug #20626] PSPP often assert-fails upon control-C
Date: Mon, 30 Jul 2007 04:05:47 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061205 Iceweasel/2.0.0.1 (Debian-2.0.0.1+dfsg-1)

URL:
  <http://savannah.gnu.org/bugs/?20626>

                 Summary: PSPP often assert-fails upon control-C
                 Project: PSPP
            Submitted by: blp
            Submitted on: Sunday 07/29/07 at 21:05
                Category: Other
                Severity: 5 - Average
                  Status: None
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                 Release: None

    _______________________________________________________

Details:

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.







    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?20626>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]