[Bug threads/11581] New: 'set scheduler-locking on' should be automatic in response to SIGABRT and SIGSEGV

[Bug threads/11581] New: 'set scheduler-locking on' should be automatic in response to SIGABRT and SIGSEGV

[k04jg02 at gmail dot com]

When debugging a multithreaded app, before printing out any function calls it's
almost always necessary to 'set scheduler-locking on', because calling a simple
getter member function will step threads, and chances are execution has stopped
in the first place because of a crash, and the crash of that thread usually
means all of the other threads are going to crash, which is going to interrupt
you as you try to print out the values you need to examine to diagnose why the
thread crashed.

You can work around this to some extent by printing raw members (unless
execution steps then too? I haven't checked) but sometimes the 'getter' in
question does a little work that's annoying to repeat by hand in GDB (e.g.
adding an offset).

I think it would be the most convenient to have scheduler-locking turn on
automatically in response to SIGABRT and SIGSEGV. GDB would also need to loudly
announce that it's turning it on to avoid confusion, and perhaps there should be
an option to disable this behavior just in case. But I hypothesize it's the
behavior users would want 99% of the time.

Combined with fixing my other bug, 11580, debugging multithreaded apps would
involve a whole lot less of typing 'set scheduler-locking on' and 'set
scheduler-locking off' over and over ;p

-- 
           Summary: 'set scheduler-locking on' should be automatic in
                    response to SIGABRT and SIGSEGV
           Product: gdb
           Version: 7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: threads
        AssignedTo: unassigned at sourceware dot org
        ReportedBy: k04jg02 at gmail dot com
                CC: gdb-prs at sourceware dot org


http://sourceware.org/bugzilla/show_bug.cgi?id=11581

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug threads/11581] 'set scheduler-locking on' should be automatic in response to SIGABRT and SIGSEGV

[k04jg02 at gmail dot com]

------- Additional Comments From k04jg02 at gmail dot com  2010-05-07 18:53 -------
Also, due to some platforms supporting scheduler-locking and some not, and due
to developers that may use GDB across multiple platforms, it might be a good
idea to print a message when it's *not* being enabled in response to
SIGABRT/SIGSEGV due to lack of support, so that developers are aware GDB may act
differently than they're accustomed to from working on another platform.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11581

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug threads/11581] 'set scheduler-locking on' should be automatic in response to SIGABRT and SIGSEGV

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=11581

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
In https://sourceware.org/bugzilla/show_bug.cgi?id=11580#c3, Pedro
asked for no special casing like this.

It seems to me you could implement it yourself by using
"catch signal".  The commands could disable scheduler-locking.

I agree that some kind of warning when scheduler-locking can't
apply would be good to have.  Maybe it could be done once
per exec target.

-- 
You are receiving this mail because:
You are on the CC list for the bug.