From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 3D4393858439 for ; Fri, 6 Oct 2023 17:01:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3D4393858439 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1696611706; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=sWSr/uzXpJFwkKfaDQnfzjSkA7cwrd2z2jWPzAfovQY=; b=LPQDnUGpjQFsAb3bdzO1rxuNPiNbb0vFSqK0Kd8I0MJfj5cYOAxggpmK32QHF/R7pq5uwB AqbSSmzlfc6FlGd7JuOkPqTp9cC2ufCQ8jbvY/dJgRkKle/llRD+tuX4ahOww9pxFoi7sU GN6mQyRlPuZwwWOpK6a6EK8xoNo8wxw= Received: from mail-oa1-f71.google.com (mail-oa1-f71.google.com [209.85.160.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-247-zviTwKoYNgS6daib3BdDlQ-1; Fri, 06 Oct 2023 13:01:45 -0400 X-MC-Unique: zviTwKoYNgS6daib3BdDlQ-1 Received: by mail-oa1-f71.google.com with SMTP id 586e51a60fabf-1e113662d75so3262848fac.3 for ; Fri, 06 Oct 2023 10:01:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696611705; x=1697216505; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=sWSr/uzXpJFwkKfaDQnfzjSkA7cwrd2z2jWPzAfovQY=; b=Ko4pTW5qnpXMBGl11Sw1DuqUjCGaLiGF2s0EcsjToeSIPfb2UYOHUcqhb8o7YqWbfr G7aUua2S4G3ssPNMp9T68KX+qgMO3DkS2hx0Zbu8qK3aXshrVo9d5Jt3+ZAABHKCjA+z p2wpqjUYam12kGbdVWyRkPxtl27RLcEN3wZQ8sU4u5E6SLCL2ODU7juNLFEOrYrBkJ+t Ose9VaS0BWqFpTAbRF9TQmYcJJlKHQFgTXqaXaEf1l4SvEu8cYM1mPwNpX0pnnFkXiB9 o4H6IxeO65v6tLrzSQAGo5GfwX3B5RpJGUv4couXNq5nzlumNhux2R2vv7503RsmPACo J43A== X-Gm-Message-State: AOJu0YxdM7vKb2i/G1cO9g/ovuyf+DS/fF/0pjzwe7PIxo+OB2FowgLt 2vUTe8c88h8y+ts7bHLMryrzn44gXTswQRYAzSkNSNSyNyfY62b6BtQabr9IsXUYLQyuRTkE/yQ NLrSS3qpjnj/iXkXbrxVDoQ== X-Received: by 2002:a05:6870:8301:b0:1d6:790f:25a0 with SMTP id p1-20020a056870830100b001d6790f25a0mr9398762oae.4.1696611704722; Fri, 06 Oct 2023 10:01:44 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFbHK8wU0hTIhleYZZbpXt/H/ftMFIREj60IvIfux3E47P3Dtj2w7MHone3WvXvv4Wtn5T3dw== X-Received: by 2002:a05:6870:8301:b0:1d6:790f:25a0 with SMTP id p1-20020a056870830100b001d6790f25a0mr9398738oae.4.1696611704256; Fri, 06 Oct 2023 10:01:44 -0700 (PDT) Received: from localhost ([31.111.84.209]) by smtp.gmail.com with ESMTPSA id p19-20020a0ccb93000000b0065d13c3b77esm1515818qvk.1.2023.10.06.10.01.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Oct 2023 10:01:43 -0700 (PDT) From: Andrew Burgess To: Thiago Jung Bauermann , Simon Marchi Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] gdb/testsuite: Bump up 'match_max' In-Reply-To: <87lechn63m.fsf@linaro.org> References: <20231003195338.334948-1-thiago.bauermann@linaro.org> <87ttr6m2j7.fsf@linaro.org> <87lechn63m.fsf@linaro.org> Date: Fri, 06 Oct 2023 18:01:42 +0100 Message-ID: <87v8bjsn0p.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Thiago Jung Bauermann via Gdb-patches writes: > Simon Marchi writes: > >> On 2023-10-04 18:43, Thiago Jung Bauermann wrote: >>> >>> Hello Simon, >>> >>> Thanks for looking into this. >>> >>> Simon Marchi writes: >>> >>>> On 2023-10-03 15:53, Thiago Jung Bauermann via Gdb-patches wrote: >>>>> This fixes "ERROR: internal buffer is full." in gdb.base/maint.exp when >>>>> running with "make check-read1". >>>>> >>>>> Also take the opportunity to fix stray whitespace in the vicinity. >>>>> --- >>>>> gdb/testsuite/lib/gdb.exp | 9 +++++---- >>>>> 1 file changed, 5 insertions(+), 4 deletions(-) >>>>> >>>>> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp >>>>> index de22da8d8a8c..c6ee4628f8f5 100644 >>>>> --- a/gdb/testsuite/lib/gdb.exp >>>>> +++ b/gdb/testsuite/lib/gdb.exp >>>>> @@ -6533,13 +6533,14 @@ proc default_gdb_init { test_file_name } { >>>>> if { $gdb_wrapper_target != [current_target_name] } { >>>>> set gdb_wrapper_initialized 0 >>>>> } >>>>> - >>>>> + >>>>> # Unlike most tests, we have a small number of tests that generate >>>>> # a very large amount of output. We therefore increase the expect >>>>> # buffer size to be able to contain the entire test output. This >>>>> - # is especially needed by gdb.base/info-macros.exp. >>>>> - match_max -d 65536 >>>>> - # Also set this value for the currently running GDB. >>>>> + # is especially needed by gdb.base/info-macros.exp and >>>>> + # gdb.base/maint.exp. >>>>> + match_max -d 196608 >>>>> + # Also set this value for the currently running GDB. >>>>> match_max [match_max -d] >>>>> >>>>> # We want to add the name of the TCL testcase to the PASS/FAIL messages. >>>> >>>> Do you have details about what fails specifically? It runs fine here, >>> >>> I think that what causes trouble is the fact that the line tables of the >>> dynamic linker are huge. >>> >>> What happens is that when testing "maint info line-table w/o a file >>> name", expect times out in the middle of "maint info line-table" output >>> while it's listing the line-table of dl-load.c. A bit after that I get >>> the first 2 "ERROR: internal buffer is full." (I get between 2 and 5 >>> such ERRORs depending on the machine). >>> >>> Then there are a few more errors while printing the line table of >>> elf/rtld.c. >>> >>>> so I'm curious which part of the test fills the buffer exactly. Also, >>> >>> Interesting. This fails on all 4 of the machines I tried, covering >>> aarch64-linux, armv8l-linux-gnueabihf and x86_84-linux. Do you have >>> libc6 debuginfo installed? >> >> I do, on my Ubuntu system, but my build wasn't configured to use it. I >> added --with-separate-debug-dir=/usr/lib/debug to my build (it defaults >> to /usr/local/lib/debug), and now my GDB picks up the debug info for >> libc. >> >> The "maint info line-table" test is specifically written in a way to >> deal with large output. It uses gdb_test_multiple with different -re >> patterns to match the different expected lines. expect reads some >> output from GDB, then tries to match any -re line. If there's a match, >> the text that matched is removed from the expect buffer. When there >> isn't enough data in the buffer, expect reads more GDB output. This >> way, we consume the GDB output line by line and avoid having all the >> huge output of the command in the buffer at the same time. >> >> See this commit: >> >> https://gitlab.com/gnutools/binutils-gdb/-/commit/f610ab6d3cbab5d8b8ef3f3a93dd81a800ec5725 >> >> I added some "puts" in each -re clause, to see which matched (see diff >> at the end). With "make check", it looks fine, this -re (which matches >> table entries) gets matched often: >> >> -re "^$decimal\[ \t\]+$decimal\[ \t\]+$hex\[ \t\]+$hex\[^\r\n\]*\r\n" >> >> But with "make check-read1", it doesn't get matched and we accumulate >> lots of output in the buffer. I follow the test execution with `tail -F >> testsuite/gdb.log` on another terminal, and I see the output coming in >> slower and slower (presumably because expect tries to match our patterns >> on an ever growing buffer). >> >> So I think this is what you should dig into, why doesn't this -re get >> matched with read1. Note that the ^ at the beginning of the regex means >> that this regex will match only against some output at the very >> beginning of the buffer. So if there is some unmatched output in the >> buffer before what this line intends to match, it won't match. >> >> The culprits are likely the regexes that finish with an unbounded >> repetition like [^\r\n]*. When characters are read one by one in the >> buffer, the regex can match early and leave something in the buffer that >> it would have otherwise matched, if the reads were done in big chunks as >> usual (this is precisely the kind of issue that read1 means to uncover). >> Those regexes would need to be modified to consume the entire line, even >> with read1. > > Thank you for the detailed explanation and for the debug patch! I'll dig > further into it and see if I can fix the testcase. The patch below is what you are looking for. Thanks, Andrew --- diff --git a/gdb/testsuite/gdb.base/maint.exp b/gdb/testsuite/gdb.base/maint.exp index c05d0987e7f..d24b0affbaf 100644 --- a/gdb/testsuite/gdb.base/maint.exp +++ b/gdb/testsuite/gdb.base/maint.exp @@ -386,11 +386,11 @@ gdb_test "maint" \ set saw_srcfile 0 gdb_test_multiple "maint info line-table" \ "maint info line-table w/o a file name" { - -re "symtab: \[^\n\r\]+${srcfile} \\(\\(struct symtab \\*\\) $hex\\)\r\nlinetable: \\(\\(struct linetable \\*\\) $hex\\):\r\nINDEX\[ \t\]+LINE\[ \t\]+REL-ADDRESS\[ \t\]+UNREL-ADDRESS\[^\r\n\]*" { + -re "symtab: \[^\n\r\]+${srcfile} \\(\\(struct symtab \\*\\) $hex\\)\r\nlinetable: \\(\\(struct linetable \\*\\) $hex\\):\r\nINDEX\[ \t\]+LINE\[ \t\]+REL-ADDRESS\[ \t\]+UNREL-ADDRESS\[^\r\n\]*\r\n" { set saw_srcfile 1 exp_continue } - -re "symtab: \[^\n\r\]+ \\(\\(struct symtab \\*\\) $hex\\)\r\nlinetable: \\(\\(struct linetable \\*\\) $hex\\):\r\nINDEX\[ \t\]+LINE\[ \t\]+REL-ADDRESS\[ \t\]+UNREL-ADDRESS\[^\r\n\]*" { + -re "symtab: \[^\n\r\]+ \\(\\(struct symtab \\*\\) $hex\\)\r\nlinetable: \\(\\(struct linetable \\*\\) $hex\\):\r\nINDEX\[ \t\]+LINE\[ \t\]+REL-ADDRESS\[ \t\]+UNREL-ADDRESS\[^\r\n\]*\r\n" { # Match each symtab to avoid overflowing expect's buffer. exp_continue }