This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]