Daniel Jacobowitz wrote:
> On Fri, Oct 13, 2006 at 12:09:24PM -0700, Michael Snyder wrote:
>> On Fri, 2006-10-13 at 12:13 +0800, Wu Zhou wrote:
>>
>>> < ERROR: internal buffer is full.
>>> < UNRESOLVED: gdb.base/checkpoint.exp: info checkpoints with at least 600 checkpoints
>>> ---
>>>  > PASS: gdb.base/checkpoint.exp: info checkpoints with at least 600 checkpoints
>>>
>>> *** Patched gdb have an internal buffer full error, which make checkpoint.exp have a unresolved case.
>> Could you run the checkpoint.exp test by itself, and post the
>> relevant portion of the gdb.log file?

Sure, here is the relevant portion, I also attach the whole log file below for your reference.

(gdb) continue^M
Continuing.^M
^M
Breakpoint 3, main () at ../../../src/gdb/testsuite/gdb.base/checkpoint.c:55^M
55        printf ("Copy complete.\n");  /* breakpoint 2 */^M
(gdb) PASS: gdb.base/checkpoint.exp: break2 with many checkpoints
info checkpoints^M
   641 process 12150 at 0x100006c4, file checkpoint.c, line 50^M
   640 process 12149 at 0x100006c4, file checkpoint.c, line 50^M
   639 process 12148 at 0x100006c4, file checkpoint.c, line 50^M
   638 process 12147 at 0x100006c4, file checkpoint.c, line 50^M
   637 process 12146 at 0x100006c4, file checkpoint.c, line 50^M
   636 process 12145 at 0x100006c4, file checkpoint.c, line 50^M
   635 process 12144 at 0x100006c4, file checkpoint.c, line 50^
.....
   3 process 11511 at 0x100006c4, file checkpoint.c, line 50^M
   2 process 11510 at 0x100006c4, file checkpoint.c, line 50^M
   1 process 11509 at 0x100006c4, file checkpoint.c, line 50^M
* 0 process 11506 (main process) at 0x10000708, file checkpoint.c, line 55^M
ERROR: internal buffer is full.
UNRESOLVED: gdb.base/checkpoint.exp: info checkpoints with at least 600 checkpoints
(gdb) kill^M
Kill the program being debugged? (y or n) y^M
(gdb) PASS: gdb.base/checkpoint.exp: kill all one


AFAICT from the log, info checkpoint in patched gdb outputs mostly, if not all, the same as what is 
outputed in the shipped gdb.  The only difference is text "ERROR: internal buffer is full."  I guess 
this is related to runtest or expect.  Because when I run these tests manually on 
gdb.base/checkpoint, "info checkpoint" will output all the 641 checkpoints quite well.

>>
>>> 11453a11453
>>>  > PASS: gdb.threads/schedlock.exp: other thread 0 didn't run
>>> 11455d11454
>>> < PASS: gdb.threads/schedlock.exp: other thread 1 didn't run
>>> 11472a11472
>>>  > PASS: gdb.threads/schedlock.exp: other thread 0 didn't run (stepping)
>>> 11474d11473
>>> < PASS: gdb.threads/schedlock.exp: other thread 1 didn't run (stepping)
>>>
>>> *** patched gdb has two PASSes which occur at different thread.
>> Could you also run this test by itself and post the gdb.log?

Sorry, I can't reproduce this.  I tried another three times, every time it will report the same 
results as in un-patched gdb:

(gdb) PASS: gdb.threads/schedlock.exp: find current thread (3)
PASS: gdb.threads/schedlock.exp: continue with lock does not change thread
print args^M
$4 = {53765598, 85573887, 52451128, 44934175, 86509672, 56510885}^M
(gdb) PASS: gdb.threads/schedlock.exp: listed args (4)
PASS: gdb.threads/schedlock.exp: other thread 0 didn't run
PASS: gdb.threads/schedlock.exp: current thread ran
PASS: gdb.threads/schedlock.exp: other thread 2 didn't run
PASS: gdb.threads/schedlock.exp: other thread 3 didn't run
PASS: gdb.threads/schedlock.exp: other thread 4 didn't run
PASS: gdb.threads/schedlock.exp: other thread 5 didn't run
step^M
58          while (*myp > 0)^M
(gdb) step^M
61              (*myp) ++;^M

I guess this is related to what Daniel said below, these tests are sensitive to load on the test 
machine.

> 
> All of these tests are timing sensitive.  I don't know why for
> checkpoint.exp - that one can probably be fixed.  For schedlock, I
> think we ought to weaken the tests somewhat; right now, it's very
> sensitive to load on the test machine.
> 

Regards
- Wu Zhou