1. 01 Jun, 2016 2 commits
  2. 31 May, 2016 1 commit
  3. 30 May, 2016 1 commit
  4. 29 May, 2016 1 commit
  5. 28 May, 2016 1 commit
  6. 27 May, 2016 1 commit
  7. 26 May, 2016 1 commit
  8. 25 May, 2016 3 commits
    • Pedro Alves's avatar
      Fix PR gdb/19828: gdb -p <process from a container>: internal error · 136613ef
      Pedro Alves authored
      When GDB attaches to a process, it looks at the /proc/PID/task/ dir
      for all clone threads of that process, and attaches to each of them.
      Usually, if there is more than one clone thread, it means the program
      is multi threaded and linked with pthreads.  Thus when GDB soon after
      attaching finds and loads a libthread_db matching the process, it'll
      add a thread to the thread list for each of the initially found
      lower-level LWPs.
      If, however, GDB fails to find/load a matching libthread_db, nothing
      is adding the LWPs to the thread list.  And because of that, "detach"
      hits an internal error:
        (gdb) PASS: gdb.threads/clone-attach-detach.exp: fg attach 1: attach
        info threads
          Id   Target Id         Frame
        * 1    LWP 6891 "clone-attach-de" 0x00007f87e5fd0790 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84
        (gdb) FAIL: gdb.threads/clone-attach-detach.exp: fg attach 1: info threads shows two LWPs
        .../src/gdb/thread.c:1010: internal-error: is_executing: Assertion `tp' failed.
        A problem internal to GDB has been detected,
        further debugging may prove unreliable.
        Quit this debugging session? (y or n)
        FAIL: gdb.threads/clone-attach-detach.exp: fg attach 1: detach (GDB internal error)
      From here:
        #8  0x00000000007ba7cc in internal_error (file=0x98ea68 ".../src/gdb/thread.c", line=1010, fmt=0x98ea30 "%s: Assertion `%s' failed.")
            at .../src/gdb/common/errors.c:55
        #9  0x000000000064bb83 in is_executing (ptid=...) at .../src/gdb/thread.c:1010
        #10 0x00000000004c23bb in get_pending_status (lp=0x12c5cc0, status=0x7fffffffdc0c) at .../src/gdb/linux-nat.c:1235
        #11 0x00000000004c2738 in detach_callback (lp=0x12c5cc0, data=0x0) at .../src/gdb/linux-nat.c:1317
        #12 0x00000000004c1a2a in iterate_over_lwps (filter=..., callback=0x4c2599 <detach_callback>, data=0x0) at .../src/gdb/linux-nat.c:899
        #13 0x00000000004c295c in linux_nat_detach (ops=0xe7bd30, args=0x0, from_tty=1) at .../src/gdb/linux-nat.c:1358
        #14 0x000000000068284d in delegate_detach (self=0xe7bd30, arg1=0x0, arg2=1) at .../src/gdb/target-delegates.c:34
        #15 0x0000000000694141 in target_detach (args=0x0, from_tty=1) at .../src/gdb/target.c:2241
        #16 0x0000000000630582 in detach_command (args=0x0, from_tty=1) at .../src/gdb/infcmd.c:2975
      Tested on x86-64 Fedora 23.  Also confirmed the test passes against
      gdbserver with "maint set target-non-stop".
      Unfortunately, making GDB add LWPs to the thread list sooner exposes
      inefficiencies that in turn result in
      gdb.threads/attach-many-short-lived-threads.exp timing out frequently.
      Since that testcase is really a contrived use case designed to stress
      some aspects of attach/detach and thread listing, not really
      representative of real programs, this commit disables the test.
      2016-05-25  Pedro Alves  <palves@redhat.com>
      	PR gdb/19828
      	* linux-nat.c (attach_proc_task_lwp_callback): Mark the lwp
      	resumed, and add the thread to GDB's thread list.
      2016-05-25  Pedro Alves  <palves@redhat.com>
      	PR gdb/19828
      	* gdb.threads/clone-attach-detach.c: New file.
      	* gdb.threads/clone-attach-detach.exp: New file.
      	* gdb.threads/attach-many-short-lived-threads.exp: Skip.
    • Pedro Alves's avatar
      Make gdb/linux-nat.c consider a waitstatus pending on the infrun side · a0de87e7
      Pedro Alves authored
      Working on the fix for gdb/19828, I saw
      gdb.threads/attach-many-short-lived-threads.exp fail once in an
      unusual way.  Unfortunately I didn't keep debug logs, but it's an
      issue similar to what's been fixed in remote.c a while ago --
      linux-nat.c was not fetching the pending status from the right place.
      2016-05-25  Pedro Alves  <palves@redhat.com>
      	PR gdb/19828
      	* linux-nat.c (get_pending_status): If the thread reported the
      	event to the core and it's pending, use the pending status signal
    • GDB Administrator's avatar
      Automatic date update in version.in · 92e19212
      GDB Administrator authored
  9. 24 May, 2016 1 commit
  10. 23 May, 2016 1 commit
  11. 22 May, 2016 1 commit
  12. 21 May, 2016 1 commit
  13. 20 May, 2016 1 commit
  14. 19 May, 2016 1 commit
  15. 18 May, 2016 3 commits
    • Simon Marchi's avatar
      Add mi-threads-interrupt.exp test (PR 20039) · cf2cd512
      Simon Marchi authored
      Add a new test for PR 20039.  The test spawns new threads, then tries to
      interrupt, continue, and interrupt again.  This use case was fixed by
      commit 5fe96654 in master, but gdb 7.11
      is affected (so if you try it on the gdb-7.11-branch right now, the test
      will fail).
      New in v2, the test now handles mi-async on mode properly.  The failure
      was specific to mi-async off, but I don't think it's bad to test the
      same thing under async on mode.  I added a little hack when running in
      async mode to work around bug 20045.
      I also removed one continue/interrupt pair, as a single one was enough to
      trigger the problem.
      	* gdb.mi/mi-threads-interrupt.c: New file.
      	* gdb.mi/mi-threads-interrupt.exp: New file.
    • Simon Marchi's avatar
      Fix double prompt output after run control MI commands with mi-async on (PR 20045) · f0a8d0dc
      Simon Marchi authored
      When you use a run control command (-exec-run, -exec-continue,
      -exec-next, ...) with mi-async on, an extra (gdb) prompt is displayed:
      It doesn't seem to be a big problem for front-ends, since this behavior
      started in gdb 7.9 and we haven't heard anything about that.  However,
      it caused me some trouble while writing a test for PR 20039 [1].
      The problem comes from an extra (gdb) prompt that we write when running
      in mi-async off mode to emulate a past buggy behavior.  When executing a
      run control command synchronously, previous gdbs always printed a prompt
      right away, even though they are not ready to accept new MI commands
      until the target stops.  Only at this time should they display a prompt.
      But to keep backwards compatibility apparently, we print it anyway.
      Since commit 198297aa, the condition that decides whether we should
      print that "bogus" prompt or not has become true, even when running with
      mi-async on.  Since we already print a prompt at the end of the
      asynchronous command execution, it results in two prompts for one
      The proposed fix is to call target_can_async_p instead of
      target_is_async_p, to make the condition:
        if (!target_can_async_p () || sync_execution)
          ... show prompt ...
      That shows the prompt if we are emulating a synchronous command on top
      of an asynchronous target (sync_execution) or if the target simply can't
      run asynchronously (!target_can_async_p ()).
      Note that this code is changed and this bug fixed by Pedro's separate
      console series, but I think it would be nice to have it fixed in the
      mean time.
      I ran the gdb.mi directory of the testsuite with mi-async on and off, I
      didn't see any regressions.
      	* mi/mi-main.c (mi_on_resume): Call target_can_async_p instead
      	of target_is_async_p.
      [1] https://sourceware.org/ml/gdb-patches/2016-05/msg00075.html
    • GDB Administrator's avatar
      Automatic date update in version.in · 2ef476ed
      GDB Administrator authored
  16. 17 May, 2016 2 commits
    • Simon Marchi's avatar
      Fix -exec-run not running asynchronously with mi-async on (PR gdb/18077) · b5f0db46
      Simon Marchi authored
      When doing -exec-run on a freshly started GDB, the only target on the
      target stack at the time the dummy one.  When mi_async_p is called to
      know whether the run should be async, it queries whether the current
      target (dummy) supports async, and the answer is no.  The fix is to make
      the code query the target that will be used for the run, which is not
      necessarily the current target.
      No regressions in the gdb.mi directory using the unix, native-gdbserver
      and native-extended-gdbserver boards.  The test doesn't pass when
      forcing maint set target-async off, obviously, since it makes mi-async
      have no effect.  It doesn't seem like other tests are checking for that
      eventuality, so I didn't in the new test.
      	* mi/mi-main.c (run_one_inferior): Use run target to determine
      	whether to run async or not.
      	(mi_cmd_exec_run): Likewise.
      	* gdb.mi/mi-async-run.exp: New file.
      	* gdb.mi/mi-async-run.c: New file.
    • GDB Administrator's avatar
      Automatic date update in version.in · bffe67e8
      GDB Administrator authored
  17. 16 May, 2016 2 commits
    • Pedro Alves's avatar
      Use target_terminal_ours_for_output in MI · 7f8e34d8
      Pedro Alves authored
      The MI code only does output, so leave raw/cooked mode alone, as well
      as the SIGINT handler.  Restore terminal settings after output, while
      at it.  Also, a couple events missed calling target_terminal_ours
      before output, even.
      [Backported to the 7.11 branch by Simon Marchi, as it fixes PR 20039.]
      YYYY-MM-DD  Pedro Alves  <palves@redhat.com>
      	* mi/mi-interp.c (mi_new_thread): Put
      	target_terminal_ours_for_output in effect while outputting.
      	(mi_thread_exit): Use target_terminal_ours_for_output instead of
      	(mi_record_changed, mi_inferior_added, mi_inferior_appeared)
      	(mi_inferior_exit, mi_inferior_removed, mi_traceframe_changed)
      	(mi_tsv_created, mi_tsv_deleted, mi_tsv_modified)
      	(mi_breakpoint_created, mi_breakpoint_deleted)
      	(mi_breakpoint_modified, mi_solib_loaded, mi_solib_unloaded)
      	(mi_command_param_changed, mi_memory_changed)
      	(report_initial_inferior): Use target_terminal_ours_for_output
      	instead of target_terminal_ours.  Restore terminal settings.
      	* mi/mi-main.c (mi_execute_command): Use
      	target_terminal_ours_for_output instead of target_terminal_ours.
      	Restore terminal settings.
    • GDB Administrator's avatar
      Automatic date update in version.in · d38ce6a6
      GDB Administrator authored
  18. 15 May, 2016 1 commit
  19. 14 May, 2016 1 commit
  20. 13 May, 2016 1 commit
  21. 12 May, 2016 1 commit
  22. 11 May, 2016 1 commit
  23. 10 May, 2016 1 commit
  24. 09 May, 2016 1 commit
  25. 08 May, 2016 1 commit
  26. 07 May, 2016 1 commit
  27. 06 May, 2016 1 commit
  28. 05 May, 2016 1 commit
  29. 04 May, 2016 1 commit
  30. 03 May, 2016 4 commits
    • Pedro Alves's avatar
      Fix gdb/python/python.c use-after-free · 329dec6f
      Pedro Alves authored
      Valgrind shows:
       ==26964== Invalid read of size 1
       ==26964==    at 0x6E14100: __GI_strcmp (strcmp.S:180)
       ==26964==    by 0x6DB55AA: setlocale (setlocale.c:238)
       ==26964==    by 0x4E0455: _initialize_python() (python.c:1731)
       ==26964==    by 0x786731: initialize_all_files() (init.c:319)
       ==26964==    by 0x72EF0A: gdb_init(char*) (top.c:1929)
       ==26964==    by 0x60BCAC: captured_main(void*) (main.c:863)
       ==26964==    by 0x606AD5: catch_errors(int (*)(void*), void*, char*, return_mask) (exceptions.c:234)
       ==26964==    by 0x60C608: gdb_main(captured_main_args*) (main.c:1165)
       ==26964==    by 0x40CAEC: main (gdb.c:32)
       ==26964==  Address 0x81d30a0 is 0 bytes inside a block of size 181 free'd
       ==26964==    at 0x4C29CF0: free (vg_replace_malloc.c:530)
       ==26964==    by 0x6DB5B65: setname (setlocale.c:201)
       ==26964==    by 0x6DB5B65: setlocale (setlocale.c:388)
       ==26964==    by 0x4E037F: _initialize_python() (python.c:1712)
       ==26964==    by 0x786731: initialize_all_files() (init.c:319)
       ==26964==    by 0x72EF0A: gdb_init(char*) (top.c:1929)
       ==26964==    by 0x60BCAC: captured_main(void*) (main.c:863)
       ==26964==    by 0x606AD5: catch_errors(int (*)(void*), void*, char*, return_mask) (exceptions.c:234)
       ==26964==    by 0x60C608: gdb_main(captured_main_args*) (main.c:1165)
       ==26964==    by 0x40CAEC: main (gdb.c:32)
      The problem is doing this:
        oldloc = setlocale (LC_ALL, NULL);
        setlocale (LC_ALL, "");
        setlocale (LC_ALL, oldloc);
      I.e., the second setlocale call frees 'oldloc'.
      From http://pubs.opengroup.org/onlinepubs/9699919799/functions/setlocale.html :
       "The returned string pointer might be invalidated or the string
       content might be overwritten by a subsequent call to setlocale()."
      2016-05-03  Pedro Alves <palves@redhat.com>
      	PR python/20037
      	* python/python.c (_initialize_python) [IS_PY3K]: xstrdup/xfree
    • Pedro Alves's avatar
      Remove gdb/python/python.c code that handles strlen failing with -1 · aaa3178d
      Pedro Alves authored
      This makes no sense -- strlen doesn't really ever fail with -1.
      2016-05-03  Pedro Alves <palves@redhat.com>
      	* python/python.c (_initialize_python) [IS_PY3K]: Remove dead
    • Kyrylo Tkachov's avatar
      [gdb] Fix -Wparentheses warnings · 386c9034
      Kyrylo Tkachov authored
      2016-05-03  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>
      	* symfile.c (find_pc_overlay): Add braces to avoid -Wparentheses
      	(find_pc_mapped_section): Likewise.
      	(list_overlays_command): Likewise.
    • GDB Administrator's avatar
      Automatic date update in version.in · 56d916d0
      GDB Administrator authored