View Issue Details

IDProjectCategoryView StatusLast Update
0000156ascendgeneralpublic2008-02-10 13:03
Reporterjohn 
Assigned Tojohn 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version0.9.6 
Summary0000156: SIGINT trap makes it difficult to debug hanging processes
DescriptionIf we take away the SIGINT trap in ASCEND it makes it easier to locate hanging processes using GDB. I will add compiler flags that allow this to be done. Are there any issues with removing the SIGINT trap for released versions?

Most other linux programs that I use don't mess around with preventing ctrl-C interrupts. If run from the console they can easily be interrupted but if from from the GUI they need to be killed in other ways.

Perhaps it's just the case the the signal handling is broken, and ctrl-C interrupt is supposed to work, actually?

How about windows?
TagsNo tags attached.

Relationships

related to 0000122 resolvedjohn Remove verbose at-startup testing of signal handling? 

Activities

john

2005-12-07 20:33

administrator   ~0000077

Reminder sent to: ben, jds

Hi there

Would be interested to have your comments on this.

Cheers
JP

john

2005-12-15 04:48

administrator   ~0000088

From Jerry:

John;

Doesn't matter much to me. My impression is that trapping ctrl-C signals will be even less important on Windows. I haven't really thought it through, though. My guess is that Ben will offer the most insightful comments about the merits of your question.

Jerry

john

2005-12-15 04:48

administrator   ~0000089

From Ben:

Ctrl-C in ascend interrupts the solver and otherwise is ignored.
My recollection is that there's a way to turn interrupt handling
on and off from tcl using one of the ascend extension functions,
which precludes the need for a special build.

re production builds, I suggest users continue to be able to
interrupt the solver with ctrl-c by default. this also comes
handy when the gui is non-responsive and you can send the
process a signal with kill (on unix anyway).

ben

john

2005-12-15 04:49

administrator   ~0000090

I think that ctrl-C should behave in the standard way and interrupt the application. An unresponsive GUI is a bug.

jds

2005-12-15 05:56

manager   ~0000091

In any case, I don't think the functionality should be turned off in ascSignal.[ch]. ascSignal just provides a signal management facility, not a compulsion to use it. This is an interface issue, and it doesn't seem that the base library should build differently depending on whether one plans to use SIGINT handling.

If there are aspects of the ascSignal implementation that are problematic (e.g. firing SIGINT during the initialization), then it's better to provide a way to modify the behavior interactively than build the library differently for different scenarios. This could be parameters to Asc_SignalInit(), or new functions to set static flags controlling the behavior.

Within the tcl/tk interface, I'm indifferent (at this point) to selective building versus an extension function.

john

2005-12-21 02:37

administrator   ~0000123

Ben added changeset 149.

Ben, just wondering about how you see this working with non-TCL GUIs? Aren't the initial traps set in ascConfig or ascSignal or somewhere like that? Perhaps this stuff should be in the base/generic code?

ben

2005-12-21 05:46

manager   ~0000137

I see the handling of ctrl-c as being specific to a particular interface (e.g. tcltk vs pygtk vs buried in an extension to matlab or excel under windows).
Therefore, the signal handling for sigint is entirely in the province of
the tickle interface. Other interfaces are not (and should not) be required
to support the documented behavior of the tickle interface wrt sigint.

john

2005-12-21 05:52

administrator   ~0000140

Deleted your note " fixed in version 154 [^] . slv_[un]trapint provides facilities to turn ctrl-c trapping on and off." -- changeset 154 related to another bug.

john

2006-05-10 02:34

administrator   ~0000326

This was resolved by turning off the signal-tests by default in the SCons build.

Issue History

Date Modified Username Field Change
2005-12-07 20:32 john New Issue
2005-12-07 20:33 john Note Added: 0000077
2005-12-15 04:48 john Note Added: 0000088
2005-12-15 04:48 john Note Added: 0000089
2005-12-15 04:49 john Note Added: 0000090
2005-12-15 05:56 jds Note Added: 0000091
2005-12-21 02:37 john Note Added: 0000123
2005-12-21 02:40 john Status new => assigned
2005-12-21 02:40 john Assigned To => ben
2005-12-21 05:46 ben Note Added: 0000137
2005-12-21 05:52 john Note Added: 0000140
2006-01-24 04:10 john Relationship added related to 0000122
2006-02-07 13:19 john Target release => 1.0
2006-02-07 13:24 john Target release 1.0 => 0.9.6
2006-05-10 02:32 john Assigned To ben => john
2006-05-10 02:34 john Status assigned => resolved
2006-05-10 02:34 john Resolution open => fixed
2006-05-10 02:34 john Note Added: 0000326
2006-06-22 07:28 john Fixed in Version => 0.9.6
2008-02-10 13:03 john Status resolved => closed