bugGNU Octave - Bugs: bug #53101, Ctrl+C no longer breaks to gdb...

 
 

bug #53101: Ctrl+C no longer breaks to gdb prompt

Submitter:  Mike Miller <mtmiller>
Submitted:  Fri 09 Feb 2018 01:07:45 AM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  None Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 09 Mar 2018 11:48:30 PM UTC, comment #7: 

OK, then I'm closing this and reclassifying as "other" instead of "regression" since we do want the separate thread for signal handling and apparently there's not really anything we can do in Octave.  If this could work differently in gdb, that would be great.  But otherwise, we do still have a way to get back to the debugger prompt.

John W. Eaton <jwe>
Group administrator
Fri 09 Mar 2018 10:04:47 PM UTC, comment #6: 

Based on what I have found so far, no I don't think there is anything Octave can do as long as you want to keep the new signal handling thread approach. I'm ok with using Ctrl+Z as a workaround.

Mike Miller <mtmiller>
Group Member
Thu 08 Mar 2018 10:00:24 PM UTC, comment #5: 

Is there anything we can do about this?

I'm lowering the severity to normal since there is a way to get back to the gdb prompt, even if it is not the usual C-c that we all know and love.

John W. Eaton <jwe>
Group administrator
Mon 12 Feb 2018 10:51:07 PM UTC, comment #4: 

Confirmed that SIGSTOP works, therefore also Ctrl+Z in Octave sends control back to gdb and allows debugging and resuming.

Mike Miller <mtmiller>
Group Member
Mon 12 Feb 2018 10:42:36 PM UTC, comment #3: 

According to https://stackoverflow.com/q/11543288/384593, which looks very similar to what Octave is now doing, a workaround is to send SIGSTOP to octave-cli from a separate program.

But apparently the whole idea of using a separate thread to wait on and catch signals including SIGINT breaks the normal mechanism of using Ctrl+C to break out of the program and interact with gdb.

Mike Miller <mtmiller>
Group Member
Mon 12 Feb 2018 09:47:00 PM UTC, comment #2: 

This is a side effect of the signal handling overhaul in c5c11b07598a.

Also affects gdb remotely attached to the octave-gui process.

Mike Miller <mtmiller>
Group Member
Mon 12 Feb 2018 07:51:43 PM UTC, comment #1: 

I'm not sure why this is happening now, but it is not intended behavior.

John W. Eaton <jwe>
Group administrator
Fri 09 Feb 2018 01:07:45 AM UTC, original submission:  

When running octave-cli under gdb, it used to be possible to


$ gdb --args octave-cli
...
(gdb) run
...
>> ^C
Thread 1 "octave-cli" received signal SIGINT, Interrupt.
...
(gdb)


Now octave seems to catch the Ctrl+C itself and not allow control to be returned to the debugger.

If this is an improvement to make Ctrl+C more robust in octave, that's ok, but is there any way to work interactively with a debugger now?

Mike Miller <mtmiller>
Group Member

 

(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 jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (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 group members can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-03-09 jwe Item GroupRegression Other
        Open/ClosedOpen Closed
    2018-03-08 jwe Severity4 - Important 3 - Normal

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code