[Bug threads/11580] scheduler-locking breaks re-runs

[Bug threads/11580] scheduler-locking breaks re-runs

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

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

--- Comment #8 from Tom Tromey <tromey at sourceware dot org> ---
Users can implement things like "tstep" now using a combination
of 'alias' and 'with'.

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

[Bug threads/11580] New: scheduler-locking breaks re-runs

[k04jg02 at gmail dot com]

If you run gdb ./myapp, and then do:

(gdb) set scheduler-locking on

You get the output:

Target 'exec' cannot support this command.

If you run, the program first, then break, and set scheduler-locking, then it
works as expected. This is fine behavior. The behavior that I don't think makes
sense is that once you've run the program once and and have stopped at a
breakpoint or signal, etc., and have set scheduler-locking to on, if you then do:

(gdb) run

scheduler-locking will be on and only your main thread will ever execute! For
consistency sake, either run should reset scheduler-locking (my preference,
though maybe there's a reason this would be a bad idea?) or you should be able
to set it before starting the app. The current behavior is unintuitive -- my app
would just appear to deadlock whenever I reran it because the main thread would
wait for another thread to join.

Tested on Solaris 10.

-- 
           Summary: scheduler-locking breaks re-runs
           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=11580

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

[Bug threads/11580] scheduler-locking breaks re-runs

[msnyder at sonic dot net]

------- Additional Comments From msnyder at sonic dot net  2010-05-12 17:36 -------
Hmm, I can see where this is a problem.

However, if you were using scheduler-mode "step", instead of "on", 
I don't think you would necessarily want to have it cleared automatically.

So maybe it should be cleared only if it is "on"?



-- 


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

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

[Bug threads/11580] scheduler-locking breaks re-runs

[k04jg02 at gmail dot com]

------- Additional Comments From k04jg02 at gmail dot com  2010-05-12 17:52 -------
Hmm. My core problem is the constant need to type "set scheduler-locking on"
after a crash and then "set scheduler-locking off" each time I want to rerun to
see if the crash is fixed. Maybe it could reset only if the app crashed from
SIGABRT or SIGSEGV, as opposed to being at the gdb console because of a
breakpoint or SIGINT?

-- 


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

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

[Bug threads/11580] scheduler-locking breaks re-runs

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2010-05-12 18:04 -------
Please no special casing like that.

IMO, auto disabling the setting behind the user, or frontend's back
is a bad idea.  Better would be to optimistically enable setting
scheduler locking when the target is exec, and instead complain/error
later if the target being resumed doesn't support it.

That is, have the "set scheduler-lock..." command implementation
confirm is it is possible to enable schedlocking on the spot iff
there's execution (target_has_execution), and, have infcmd.c, `proceed', or
`resume' complain is scheduler locking is on, but the current target
doesn't support it.


-- 


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

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

[Bug threads/11580] scheduler-locking breaks re-runs

[dje at google dot com]

------- Additional Comments From dje at google dot com  2010-05-13 16:46 -------
I think one needs to separate the handling of scheduler-locking when the current 
target can't handle it from the handling of scheduler-locking on a re-run.

In the re-run case, having scheduler-locking on at the start of program 
execution can cause confusion / headaches.

scheduler-locking is a session variable, when often what one wants is to just 
enable scheduler-locking temporarily - it's an attribute of the next command, 
not the entire session.  i.e. maybe instead of scheduler-locking=on we had 
tstep, tnext, tcontinue (or continue -t or whatever) that just 
step'd/next'd/continue'd/etc. the current thread only.


-- 


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

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

[Bug threads/11580] scheduler-locking breaks re-runs

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2010-05-13 17:12 -------
Note that if gdb was more permissive with allowing disabling schedlock when
the target is exec (you can't _disable_ it currently, that's dumb),
you could just add this to .gdbinit:

define hook-run
 set scheduler-locking off
end

and so every "run" would disable schedlock.

(do the same for "attach" and "start")


-- 


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

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

[Bug threads/11580] scheduler-locking breaks re-runs

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2010-05-13 17:17 -------
Yes, though command proliferation whenever we need a new flag, is probably
not that great, and is limited, e.g., expression evaluation (infcalls) may
need locking as well (for p, x, and others).  HPD's (and TotalView's) ptsets 
handle that nicely, IMO, with syntax that allows scoping a command to a
thread process, or thread group.  We have some work in that direction  
implemented in the old multiprocess branch in cvs, in the form of
itsets (inferior thread sets).  Unfortunately, that never made it to
completion.


-- 


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

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

[Bug threads/11580] scheduler-locking breaks re-runs

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2010-05-13 17:21 -------
(I missed the "continue -t" which is fine as well)

-- 


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

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