From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27383 invoked by alias); 14 Aug 2002 16:06:04 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 27334 invoked from network); 14 Aug 2002 16:06:03 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 14 Aug 2002 16:06:03 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17f0ep-0001sE-00; Wed, 14 Aug 2002 11:06:03 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17f0fB-0001AB-00; Wed, 14 Aug 2002 12:06:25 -0400 Date: Wed, 14 Aug 2002 09:06:00 -0000 From: Daniel Jacobowitz To: Fernando Nasser Cc: gdb-patches@sources.redhat.com, Michael Snyder Subject: Re: RFA (threads testsuite): More thread tests Message-ID: <20020814160625.GA3463@nevyn.them.org> Mail-Followup-To: Fernando Nasser , gdb-patches@sources.redhat.com, Michael Snyder References: <20020709154033.GA7204@nevyn.them.org> <3D598B15.524EC321@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D598B15.524EC321@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-08/txt/msg00347.txt.bz2 On Tue, Aug 13, 2002 at 06:41:25PM -0400, Fernando Nasser wrote: > Daniel Jacobowitz wrote: > > > > Here's two tests I had lying around from when I developed the gdbserver > > threads support. Gdbserver passes them with flying colors (if you use my > > other patch which lets gdbserver run tests properly). GDB shows a couple of > > problems, unpredictably (not always repeatable). > > > > Can you elaborate on what these problems are and on which host you've > seen them? They vary greatly, unfortunately. They're all reproducible but not necessarily repeatable; run the tests a half-dozen times and you'll probably see them. My system is SMP which makes things even more timing-dependant. >From one run just now: FAIL: gdb.threads/print-threads.exp: Running threads (slow with kill breakpoint) (unknown output) FAIL: gdb.threads/schedlock.exp: continue with lock does not change thread (switched to thread 4) FAIL: gdb.threads/schedlock.exp: other thread 0 didn't run (ran) FAIL: gdb.threads/schedlock.exp: other thread 2 didn't run (ran) FAIL: gdb.threads/schedlock.exp: other thread 3 didn't run (ran) FAIL: gdb.threads/schedlock.exp: other thread 4 didn't run (ran) FAIL: gdb.threads/schedlock.exp: other thread 5 didn't run (ran) FAIL: gdb.threads/schedlock.exp: step with lock does not change thread (switched to thread 4) FAIL: gdb.threads/schedlock.exp: current thread stepped locked (didn't run) FAIL: gdb.threads/schedlock.exp: other thread 4 didn't run (stepping) (ran) The first one is: Cannot find thread 4101: no thread to satisfy query The second set are some problem with set scheduler-locking that causes GDB to lose control of some threads. I don't remember why this happens, if I ever knew. The third set involve stopping in the wrong thread. You may have seen that, about three months ago now (?) I committed a multi-thread support package for gdbserver. These tests were written while I was developing it. If you run the testsuite against gdbserver (which requires a little fiddling with the test harness still...) all of these tests will pass. They sure didn't when I was working on it, though, which is why I wrote them :) > > OK to add these? > > > > Michael Snyder, have you seen these? > > > Daniel, in the meanwhile please fix your CL entries. > After the "New file." please briefly say what the new files are for. > > Also, we need some comments in the new testfile headers saying > what the tests are testing. So far we have to infer from the file names > ;-) In my defense, the first point is against GNU ChangeLog policy - you aren't supposed to explain the "why" of things in ChangeLogs. I don't really like that policy, so I'll be glad to elaborate :) I'll take care of the comments too. > Are there some lines missing in your get_current_thread proc? > The second part is after a return that seem orphan in there. Extra lines, actually. Only the part before the return is supposed to be there, thanks for spotting that. Thanks for the comments; I'll repost after Michael gets a chance to comment on the tests themselves. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer