See also bug 14236.
I'd be interested to know if the patch for that fixes this (possible).

I use gdb-7.7.1 and the changes from https://sourceware.org/ml/gdb-patches/2014-07/msg00304.html were already applied.

In 7.7.1 I applied only the patch from gdb/infcmd.c on interrupt_target_command(), because there is no interrupt_command().  I cannot link gdb:

infcmd.o: In function `wait_thread_stopped':
gdb-7.7.1/gdb/infcmd.c:2818: undefined reference to `print_stop_event'
infcmd.o: In function `interrupt_target_command':
gdb-7.7.1/gdb/infcmd.c:2921: undefined reference to `prepare_execution_command'

Please provide patch toward gdb771.

Sample program, that leads to the described error:

#include <iostream>
#include <unistd.h>
#include <thread>

void f() {
  std::cout << "A" << std::endl;
  sleep (10);
  std::cout << "Z" << std::endl;
}

int main() {
  std::thread t1 { f }; std::thread t2 { f };
  std::thread t3 { f }; std::thread t4 { f };
  std::thread t5 { f }; std::thread t6 { f };
  std::thread t7 { f }; std::thread t8 { f };
  std::thread t9 { f }; std::thread t10 { f };
  std::thread t11 { f }; std::thread t12 { f };
  sleep (15);
  t1.join(); t2.join(); t3.join(); t4.join(); t5.join(); t6.join();
  t7.join(); t8.join(); t9.join(); t10.join(); t11.join(); t12.join();
}

I applied the patches from Bug 14236 against the master branch.  gdb still crashes with the message:
  readline: readline_callback_read_char() called with no handler!

I call "interrupt -a &", as without the ampersand the control does not return to the CLI (and thus I cannot execute several <RET>s after the "interrupt -a" command).

(In reply to dilyan.palauzov@aegee.org from comment #3)
> I applied the patches from Bug 14236 against the master branch.  gdb still
> crashes with the message:
>   readline: readline_callback_read_char() called with no handler!
> 
> I call "interrupt -a &", as without the ampersand the control does not
> return to the CLI (and thus I cannot execute several <RET>s after the
> "interrupt -a" command).

Thanks.
Can I trouble you to include the backtrace (since you were gracious enough to include one for 7.7)?  Thanks!

(In reply to Doug Evans from comment #4)
> (In reply to dilyan.palauzov@aegee.org from comment #3)
> > I applied the patches from Bug 14236 against the master branch.  gdb still
> > crashes with the message:
> >   readline: readline_callback_read_char() called with no handler!
> > 
> > I call "interrupt -a &", as without the ampersand the control does not
> > return to the CLI (and thus I cannot execute several <RET>s after the
> > "interrupt -a" command).
> 
> Thanks.
> Can I trouble you to include the backtrace (since you were gracious enough
> to include one for 7.7)?  Thanks!

No need, thanks.
I was able to repro this with the following script.

---snip---
set trace-commands on
set height 22
set editing on
set non-stop on
file ~/src/play/16809.x64
run &
interrupt -a &
---snip---

bash$ ./gdb -D ./data-directory <foo.gdb

One may have to experiment with the value of height in order to trigger the bug.
22 worked for me.

(In reply to Doug Evans from comment #5)
> (In reply to Doug Evans from comment #4)
> > (In reply to dilyan.palauzov@aegee.org from comment #3)
> > > I applied the patches from Bug 14236 against the master branch.  gdb still
> > > crashes with the message:
> > >   readline: readline_callback_read_char() called with no handler!
> > > 
> > > I call "interrupt -a &", as without the ampersand the control does not
> > > return to the CLI (and thus I cannot execute several <RET>s after the
> > > "interrupt -a" command).
> > 
> > Thanks.
> > Can I trouble you to include the backtrace (since you were gracious enough
> > to include one for 7.7)?  Thanks!
> 
> No need, thanks.
> I was able to repro this with the following script.
> 
> ---snip---
> set trace-commands on
> set height 22
> set editing on
> set non-stop on
> file ~/src/play/16809.x64
> run &
> interrupt -a &
> ---snip---

Correction, cut-n-paste error.

---snip---
set trace-commands on
set height 22
set editing on
set non-stop on
file ~/src/play/16809.x64
run &
interrupt -a &





---snip---

Data point:
I can crash gdb in a similar way by applying this patch to an unpatched copy of trunk, and then using the following script.

---snip--- patch
diff --git a/gdb/linux-thread-db.c b/gdb/linux-thread-db.c
index 15902d8..2628fba 100644
--- a/gdb/linux-thread-db.c
+++ b/gdb/linux-thread-db.c
@@ -823,7 +823,7 @@ try_thread_db_load_1 (struct thread_db_info *info)
       if (library == NULL)
        library = LIBTHREAD_DB_SO;
 
-      printf_unfiltered (_("Using host libthread_db library \"%s\".\n"),
+      printf_filtered (_("Using host libthread_db library \"%s\".\n"),
                         library);
     }
 
---snip---

---snip--- foo.gdb
set editing on
set height 2
file ~/src/play/forever-threads.x64
run &

shell sleep 1



---snip---

forever-threads.x64 is the testcase from bug 17147.

Repro:

[dje@seba gdb]$ ./gdb -D ./data-directory <foo.gdb 
GNU gdb (GDB) 7.8.50.20140712-cvs
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) (gdb) set height 2
(gdb) file ~/src/play/forever-threads.x64
Reading symbols from ~/src/play/forever-threads.x64...done.
(gdb) run &
---Type <return> to continue, or q <return> to quit---
Starting program: /home/dje/src/play/forever-threads.x64 
(gdb) shell sleep 1
(gdb) 
(gdb) [Thread debugging using libthread_db enabled]
---Type <return> to continue, or q <return> to quit---
Using host libthread_db library "/lib64/libthread_db.so.1".
readline: readline_callback_read_char() called with no handler!
Aborted (core dumped)

For reference sake, see also bug 17072.

The patches for PR17072 are now in both master and the 7.8 branch.  Does this readline abort still trigger ?

The readline abort does not trigger anymore.

However, when I do "interrupt -a", gdb prints the prompt, followed by information about individual threads, and eventually puts the cursor on a very biginning of new line (not immediately after the prompt).  This unclear state was the reason to press several times <RET> and to discover this bug.

Does pagination still break non-stop?  If not, remove the relevant text from gdb/doc/gdb.texinfo , node "Non-Stop mode", line 5781-5784.

(In reply to dilyan.palauzov@aegee.org from comment #10)
> However, when I do "interrupt -a", gdb prints the prompt, followed by
> information about individual threads, and eventually puts the cursor on a
> very biginning of new line (not immediately after the prompt).  This unclear
> state was the reason to press several times <RET> and to discover this bug.
> 
> Does pagination still break non-stop?  If not, remove the relevant text from
> gdb/doc/gdb.texinfo , node "Non-Stop mode", line 5781-5784.

The issue here is that messages can be printed by gdb (e.g. to report thread state changes) even while gdb is at the prompt waiting for user input.  This is gdb's async mode and it's now the default.  The "interrupt" command has a bug in that it operates asynchronously (as if you had added a "&") by default.
What should happen is that "interrupt" or "interrupt -a" without an "&" should operate synchronously and not print the gdb prompt until the command has succeeded (just like commands that resume the inferior like run, continue, etc.).

(In reply to Doug Evans from comment #11)
> What should happen is that "interrupt" or "interrupt -a" without an "&"
> should operate synchronously and not print the gdb prompt until the command
> has succeeded (just like commands that resume the inferior like run,

s/succeeded/completed/

> continue, etc.).

> Does pagination still break non-stop?  If not, remove the relevant text from
> gdb/doc/gdb.texinfo , node "Non-Stop mode", line 5781-5784.

Yeah, that text could use an update / clarification, thanks.

It doesn't break it in the sense that there are no other known issues that weren't fixed by the fixes for PR17072 (both in master and 7.8).

But it still "breaks" it in the sense that if pagination occurs, target event processing is paused until the user proceeds with the pagination.  So, e.g., if the target needs hits a breakpoint that isn't supposed to be reported and needs to be stepped over, it'll remain paused until the pagination is proceeded.