From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id szFtE8v5LGH9cAAAWB0awg (envelope-from ) for ; Mon, 30 Aug 2021 11:31:23 -0400 Received: by simark.ca (Postfix, from userid 112) id 3D7161EE1C; Mon, 30 Aug 2021 11:31:23 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 0ED5C1E813 for ; Mon, 30 Aug 2021 11:31:22 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AFA113857835 for ; Mon, 30 Aug 2021 15:31:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AFA113857835 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1630337481; bh=ivO8WZx/Z3HTGfUtnLXoccnhx0/DVk3LPoH9ycweaD8=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=CSm5lgNPykBVgP6soqnMpFYWtd4y2gn8b+KOLp3WffnQ6dG/zdPxJIlFOvO0qnMLZ IgitoFhWid7Igtmjj6qnePZkcyiE6kEw5RWGRhJYvuApMDif9qzk/ScMUp7uFjCYIN IOq4dS291it7NUJ9p5ozSydU/WKqqlPsSopxIzdQ= Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id CFDB93858417 for ; Mon, 30 Aug 2021 15:30:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CFDB93858417 Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 11316200D5; Mon, 30 Aug 2021 15:30:53 +0000 (UTC) Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap1.suse-dmz.suse.de (Postfix) with ESMTPS id EE838139A5; Mon, 30 Aug 2021 15:30:52 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap1.suse-dmz.suse.de with ESMTPSA id B1kXOaz5LGG+FgAAGKfGzw (envelope-from ); Mon, 30 Aug 2021 15:30:52 +0000 Subject: Re: [RFC][gdb/testsuite] Add check-readmore To: Simon Marchi , gdb-patches@sourceware.org References: <20210608072444.GA3547@delia> <5abb7e45-c1e1-b8f9-125c-334353a5396b@polymtl.ca> Message-ID: <2054837a-eb79-9729-4679-22365f082a62@suse.de> Date: Mon, 30 Aug 2021 17:30:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <5abb7e45-c1e1-b8f9-125c-334353a5396b@polymtl.ca> Content-Type: multipart/mixed; boundary="------------3E2906F1BAF4C8BAD483B87C" Content-Language: en-US X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Tom de Vries via Gdb-patches Reply-To: Tom de Vries Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" This is a multi-part message in MIME format. --------------3E2906F1BAF4C8BAD483B87C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 8/26/21 5:09 AM, Simon Marchi wrote: > > > On 2021-06-08 3:24 a.m., Tom de Vries wrote: >> Hi, >> >> Consider the gdb output: >> ... >> 27 return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M >> (gdb) ^M >> Thread 2 "run-attach-whil" stopped.^M >> ... >> >> When trying to match the gdb prompt using gdb_test which uses '$gdb_prompt $', >> it may pass or fail. >> >> This sort of thing needs to be fixed (see commit b0e2f96b56b), but there's >> currently no way to reliably find this type of FAILs. >> >> We have check-read1, but that one actually make the test pass reliably. >> >> We need something like the opposite of check-read1: something that makes >> expect read a bit slower, or more exhaustively. >> >> Add a new test target check-readmore that implements this. >> >> Atm there are still two methods of implementing this in read1.c: >> - the first method waits a bit before doing a read >> - the second method does a read and then decides whether to >> return or to wait a bit and do another read. >> >> Atm the first method is enabled by default, given that it is more foolproof. >> The second method tries to be smart about waiting less than the first method, >> but consequently needs to make decisions about error codes, which is more >> fragile. >> >> Tested on x86_64-linux, both with method 1 and 2. >> >> Any comments? > > Is there an advantage to method 2 over method 1? Yes. Consider attached debug patch, and then running test-case gdb.base/info-macros.exp: ... $ rm -f LOG; ./test.sh -readmore ... which gives us attached LOG.gz. We get sequences like this: ... READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 4096 READ: fd: 5, COUNT: 4096, RES: 2659 ... With method 1, we wait some time before for _each_ read. With method 2, we wait some time after the last read, and only for that read. There's an incentive to increase sleep time, because larger sleep time has the potential of catching more errors. OTOH there's an incentive to not let sleep time to grow to large because that will cause unnecessary timeouts. The first method multiplies sleep time quite rapidly and will hit the timeouts sooner than method 2. And besides the timeouts, method 2 is faster than method 1. The drawback of method2 is that it's technically more complicated: it inspects the return status of read, and potentially does a second read. It needs to know whether to do the second read, and it needs to know which errors from the second read to ignore. There's simply more scope for errors and corner-cases. > If not, I'd just go > with the simplest. I could imagine a modified method 2 version where we > read in a loop though, until we reached "count" bytes or the file > descriptor has no more data to offer (still with a 10ms wait between > each read, to give the writer time to produce more data). Agreed, there could be some benefit in doing this in a loop. It would add a benefit similar to increasing the timeout, without the drawback of waiting unnecessary while the buffer is already full. Thanks, - Tom --------------3E2906F1BAF4C8BAD483B87C Content-Type: text/x-patch; charset=UTF-8; name="0002-debug.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="0002-debug.patch" debug --- gdb/testsuite/lib/read1.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/gdb/testsuite/lib/read1.c b/gdb/testsuite/lib/read1.c index 1f3cd4393a1..eded36d6c1f 100644 --- a/gdb/testsuite/lib/read1.c +++ b/gdb/testsuite/lib/read1.c @@ -32,6 +32,7 @@ ssize_t read (int fd, void *buf, size_t count) { static ssize_t (*read2) (int fd, void *buf, size_t count) = NULL; + static FILE *log = NULL; if (read2 == NULL) { /* Use setenv (v, "", 1) rather than unsetenv (v) to work around @@ -40,6 +41,7 @@ read (int fd, void *buf, size_t count) for existence from another interp". */ setenv ("LD_PRELOAD", "", 1); read2 = dlsym (RTLD_NEXT, "read"); + log = fopen ("/home/vries/gdb_versions/devel/LOG", "a"); } #ifdef READMORE @@ -48,10 +50,13 @@ read (int fd, void *buf, size_t count) #if 1 /* READMORE, method 1. */ +#if 0 if (isatty (fd) != 0) usleep (10 * 1000); - return read2 (fd, buf, count); - +#endif + ssize_t res = read2 (fd, buf, count); + fprintf (log, "READ: fd: %d, COUNT: %zd, RES: %zd\n", fd, count, res); + return res; #else /* READMORE, method 2. */ ssize_t res, res2; --------------3E2906F1BAF4C8BAD483B87C Content-Type: application/gzip; name="LOG.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="LOG.gz" H4sICHzzLGEAA0xPRwDtXF1u2zAMft8pfIAWEEnJEvM2bH1tgWy7wbD7H2EBtqFKIUd2P9XS HL4FyKePFP9Eyk7OT5+/nqZfP0+TPExfXn48fz9N3un8MJ2fvv35+On8f2FEJdQwLgOEFYIM MziGZwo1TNXpweEcTBEniSwwRyvLhjSOLqNhxMUqpolxiL2aFwbAkHo8vVcVNBerPG0EyT4b 8g0K9DoP0S5yJPA+KSmO9tkR+WilfvlcV9w4HIO/SwtLmtNdbtwwhjGMYQxjGMPU7nDCPh11 wod2djPeDhK5fboiknvtO3Wv6XZHDCW3yZuxHBKkNUyV5I22RYxcTa/vk3PJE5xkjbIXq6T3 CaJ/DNm3RK/rNy+eS7Ifc4TeFi6thceyD1avXzDt6vXM2PoEy2/pPXK33ecB9+no0um29ABI z3aWiQ9Szv31DEyoDqgG5HsrIJ0V8OUja0MYwD5ETaDoFlAbwnmAbmB9FV5KxNDbBChBgDVA w5D6F5MN7cCCEVANGNWAYm8jRtgIEQ4lQYvqpeuGGfBgQKsKwWWBGI0n2tCiLjHAvmC0tOC+ 4A2zwhIDmhcNGBZG9C06wPGgqfdxS0HRXXgHx2SIqB08nlpjKKFoYDdwx+zRfVw+wsY0CqMo DgjSvWh2b02Z0DN4DGcaxQEphGY0Og+QoQntL8dwplEckEJI4RkOvrBW+HZEkqJ5PoY/jGI0 CvGKXmAe4AyDbTCGM43igBRvfh92lxna/VEXXmKCneBGMSgFR/hCF87Q7o+SGX67RzTaLGwU HzPIzmiG4k/YHdwlC3oIKjwISxBr9o3iQ5KUYx5a2fuvzPIXkydh/mr3K8sVovrHMxnHghCp AYp7uULwBi2K5mr/Li5+7fxYK6i/AToReH/XSAAA --------------3E2906F1BAF4C8BAD483B87C--