From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2601 invoked by alias); 17 Mar 2008 11:00:04 -0000 Received: (qmail 2529 invoked by uid 22791); 17 Mar 2008 11:00:01 -0000 X-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_34,J_CHICKENPOX_56 X-Spam-Check-By: sourceware.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (83.160.170.119) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 17 Mar 2008 10:59:38 +0000 Received: from wildebeest.demon.nl ([83.160.170.119] helo=[127.0.0.1]) by gnu.wildebeest.org with esmtp (Exim 4.63) (envelope-from ) id 1JbD3x-000786-J2; Mon, 17 Mar 2008 11:59:35 +0100 Subject: Re: [SCM] master: Add INFO log-level; use warning level instead of System.out.println. From: Mark Wielaard To: frysk@sourceware.org Cc: Andrew Cagney In-Reply-To: <1205492803.27548.33.camel@dijkstra.wildebeest.org> References: <20080313192850.25428.qmail@sourceware.org> <1205492803.27548.33.camel@dijkstra.wildebeest.org> Content-Type: text/plain Date: Mon, 17 Mar 2008 11:00:00 -0000 Message-Id: <1205750862.7607.35.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-3.fc8) Content-Transfer-Encoding: 7bit X-Spam-Score: -3.9 (---) X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2008-q1/txt/msg00152.txt.bz2 Hi Andrew, On Fri, 2008-03-14 at 12:06 +0100, Mark Wielaard wrote: > On Thu, 2008-03-13 at 19:28 +0000, cagney@sourceware.org wrote: > > commit 2404d069602dc2b49eb5355039d2ed59c0e1cfb7 > > Author: Andrew Cagney > > Date: Thu Mar 13 15:27:22 2008 -0400 > > [...] > > frysk-sys/frysk/rsl/ChangeLog > > 2008-03-13 Andrew Cagney > > > > * Log.java (prefixTimeAndPid()): For WARNING/INFO, include level. > > * LogFactory.java (info(Class)): New. > > (info(String)): New. > > * Level.mkenum (INFO): New; make default. > > This seems to be causing: > > testLevelComparison(frysk.rsl.TestLog)junit.framework.AssertionFailedError: DEFAULT expected: but was: > at frysk.rsl.TestLog.testLevelComparison(TestRunner) > at frysk.junit.Runner.runCases(TestRunner) > at frysk.junit.Runner.runTestCases(TestRunner) > at TestRunner.main(TestRunner) > > Also filed as bug #5937. You seem to have fixed this with: commit 963501ea208d03400e55c48ff8e28053f6b8e5b7 Author: Andrew Cagney Date: Fri Mar 14 16:07:14 2008 -0400 Separate out/fix DEFAULT test. frysk-sys/frysk/rsl/ChangeLog 2008-03-14 Andrew Cagney I closed the bug for you. > I am also seeing the following since yesterday: > > 2) testBlockingFibonacciClone(frysk.proc.live.TestTaskObserverBlocked)java.lang.RuntimeException: {frysk.proc.live.LinuxPtraceTask@319faf55,pid=18639,tid=18640,state=detached} in state "detached" did not handle handleStoppedEvent SIGSTOP(19) > at frysk.proc.live.State.unhandled(TestRunner) > at frysk.proc.live.LinuxPtraceTaskState.handleStoppedEvent(TestRunner) > at frysk.proc.live.LinuxPtraceTask.processStoppedEvent(TestRunner) > at frysk.proc.live.LinuxWaitBuilder.stopped(TestRunner) > at frysk.sys.Wait.wait(TestRunner) > at frysk.sys.Wait.wait(TestRunner) > at frysk.event.WaitEventLoop.block(TestRunner) > at frysk.event.EventLoop.runEventLoop(TestRunner) > at frysk.event.EventLoop.runPolling(TestRunner) > at frysk.testbed.TestLib.assertRunUntilStop(TestRunner) > at frysk.testbed.TestLib.assertRunUntilStop(TestRunner) > at frysk.proc.live.TestTaskObserverBlocked.access$2(TestRunner) > at frysk.proc.live.TestTaskObserverBlocked$BlockingFibonacci.(TestRunner) > at frysk.proc.live.TestTaskObserverBlocked$1$CloneFibonacci.(TestRunner) > at frysk.proc.live.TestTaskObserverBlocked.testBlockingFibonacciClone(TestRunner) > at frysk.junit.Runner.runCases(TestRunner) > at frysk.junit.Runner.runTestCases(TestRunner) > at TestRunner.main(TestRunner) > > Which I haven't tracked down to a specific commit yet. Bugzilla has it > as issue #3937. Might it be caused by one of your new StopEventLoop > patches from yesterday? If you could explain what those new patches do > that would be nice. I don't see this issue anymore. Do you know what fixed it? And could you describe what your new StepEventLoop patches should accomplish? Thanks, Mark