This is the mail archive of the gdb-patches@sources.redhat.com 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]

Re: [patch] New thread test to exercise Daniel's Patch


Daniel Jacobowitz wrote:
On Mon, Mar 29, 2004 at 01:06:07PM -0500, Jeff Johnston wrote:

+send_gdb "continue\n"
+gdb_expect {


Everywhere you're using gdb_expect, please use gdb_test_multiple
instead.  For the "after" tests, you can use gdb_test_multiple with
"" as the first argument.


I tried this initially but I kept getting "Error: internal buffer is full". I tried lowering the "after" time which is why it ended up 100 below but that didn't solve the problem. Any suggestions on how to avoid the "full_buffer" error.


I'm not sure about the regexes, since I'm just pulling this out of the
top of my head, but you want something like this:

  -re "error:.*$gdb_prompt $" {
    fail "msg"
  }
  -re "\\\[New thread \[^\]\]*\\\]\r\n" {
    exp_continue
  }
  -re "\\\[Thread \[^\]\]* exited\\\]\r\n" {
    exp_continue
  }

That will consume any thread create/delete messages, instead of leaving
them in the buffer.


Forgive my ignorance of the test macros, but how does this terminate? I tried doing it this way and it hangs. It never gets a gdb prompt and spits out endless messages because it is essentially an infinite loop. I only care to see the "Continuing" message and don't care about the rest of the stuff.


I stole the original send_gdb / gdb_expect code from schedlock.exp which has the same problem.

-- Jeff J.


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