Thread: gdb problem in multi-threaded app

  1. #1
    Registered User
    Join Date
    Aug 2002
    Location
    Hermosa Beach, CA
    Posts
    446

    gdb problem in multi-threaded app

    Having a problem with gdb on fedora core 2. gdb version:

    (gdb) show version
    GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh)
    Copyright 2003 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type "show copying" to see the conditions.
    There is absolutely no warranty for GDB. Type "show warranty" for details.
    This GDB was configured as "i386-redhat-linux-gnu".
    (gdb)

    Problem is that I am trying to step through a function. The program is multi-threaded. As I am stepping, gdb automatically switches to some other thread. If I do:
    (gdb) thread 33
    or whatever to switch back to the thread that I am trying to debug, it has continued along, i.e. it isn't at the same line (or even the same function) where I was left previously.

    Isn't there some way to have the debugger NOT switch threads on me?? I know that's probably useful for some people some of the time, but for the most part it's just ..........ing annoying. From my perspective anyway.

    Thanks.
    The crows maintain that a single crow could destroy the heavens. Doubtless this is so. But it proves nothing against the heavens, for the heavens signify simply: the impossibility of crows.

  2. #2
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    I now it's annoying. It's by design. If you have no control over the locking mechanism when you step another thread may run and if it hits an exception, a signal, or a breakpoint it will request control from the debugger. You will then have to move back to your previous thread. And by doing so you may find yourself somewhere else in it.

    I don't know about your linux distro, since the solution is heavily OS dependant. But what you want is to:
    (gdb) set scheduler-locking on
    When you step no other thread will run. Only the current one. if you next, other threads may or may not run. If you continue they will definitely run.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 2
    Last Post: 05-19-2004, 07:24 PM
  2. gdb drive me crazy!!!!
    By gandalf_bar in forum Linux Programming
    Replies: 5
    Last Post: 04-07-2004, 06:38 AM
  3. Win32 C++ app problem
    By kwm32 in forum Windows Programming
    Replies: 4
    Last Post: 03-19-2004, 03:38 AM
  4. Replies: 5
    Last Post: 12-03-2003, 05:47 PM
  5. problem with output
    By Garfield in forum C Programming
    Replies: 2
    Last Post: 11-18-2001, 08:34 PM