From: Arthur Cohen <arthur.cohen@embecosm.com>
To: Thomas Schwinge <thomas@codesourcery.com>,
Philip Herron <philip.herron@embecosm.com>
Cc: Mark Wielaard <mark@klomp.org>,
buildbot@builder.wildebeest.org, gcc-rust@gcc.gnu.org
Subject: Re: Buildbot failure in Wildebeest Builder on whole buildset
Date: Wed, 2 Mar 2022 13:05:30 +0100 [thread overview]
Message-ID: <77b8bfab-7e29-a18c-39f8-acc033573ee1@embecosm.com> (raw)
In-Reply-To: <87ee3klldm.fsf@dem-tschwing-1.ger.mentorg.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 9470 bytes --]
Hi everyone,
On 3/2/22 11:05, Thomas Schwinge wrote:
> Hi!
>
> On 2022-03-02T10:44:38+0100, I wrote:
>> On 2022-03-02T09:03:48+0000, Philip Herron <philip.herron@embecosm.com> wrote:
>>> Yet again the build bots are out doing github automation :D. Would you
>>> be able to give Arthur access to the failing buildbot to test his fix?
>>
>> I suggest as a first step to figure out why your local build aren't
>> running into this issue. What does running 'build-gcc/gcc/xgcc -v'
>> should for you, and 'grep -i checking build-gcc/gcc/auto-host.h'?
>>
>>> We think we know what the issue is. We changed the lexer so we could
>>> give it a buffer instead of a file for macro expansion, but the string
>>> is going out of scope when we set it up.
>>
>> Ah! So, "standard C/C++ undefined behavior, memory corruption"... ;-)
>
> Indeed. Building GCC with '--enable-valgrind-annotations' and running
> the GCC self-test through '-wrapper valgrind,--leak-check=full', we see:
>
> $ [...]/build-gcc/./gcc/xgcc -B[...]/build-gcc/./gcc/ -xrs -nostdinc /dev/null -S -o /dev/null -fself-test=[...]/source-gcc/gcc/testsuite/selftests -wrapper valgrind,--leak-check=full
> ==3228208== Memcheck, a memory error detector
> ==3228208== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==3228208== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
> ==3228208== Command: [...]/build-gcc/./gcc/rust1 /dev/null -quiet -dumpbase null -mtune=generic -march=x86-64 -fself-test=[...]/source-gcc/gcc/testsuite/selftests -o /dev/null -L[...]/build-gcc/./gcc -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
> ==3228208==
> rust1: error: unexpected character ‘1’
> rust1: error: unexpected character ‘0’
> rust1: error: unexpected character ‘0’
> rust1: error: unexpected character ‘0’
> rust1: error: unexpected character ‘1’
> rust1: error: unexpected character ‘0’
> rust1: error: unexpected character ‘0’
> rust1: error: unexpected character ‘0’
> ==3228208== Conditional jump or move depends on uninitialised value(s)
> ==3228208== at 0x983D5E: Rust::Lexer::build_token() (rust-lex.cc:365)
> ==3228208== by 0x987DB4: Rust::buffered_queue<std::shared_ptr<Rust::Token>, Rust::Lexer::TokenSource>::peek(int) (rust-lex.h:233)
> ==3228208== by 0x988A46: Rust::parse_cfg_option(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (rust-lex.h:166)
> ==3228208== by 0x988D83: selftest::rust_cfg_parser_test() (rust-cfg-parser.cc:67)
> ==3228208== by 0x96C5EE: selftest::run_rust_tests() (rust-lang.cc:457)
> ==3228208== by 0x2527223: selftest::run_tests() (selftest-run-tests.cc:119)
> ==3228208== by 0x11C2C29: toplev::run_self_tests() (toplev.cc:2217)
> ==3228208== by 0x96991B: toplev::main(int, char**) (toplev.cc:2317)
> ==3228208== by 0x96BFD6: main (main.cc:39)
> [...]
>
> Before commit 6cf9f8c99c5813a23d7cec473fedf00683f409e4 "Merge #983", that
> was "clean" (just some lost memory etc.).
Thanks a lot for this. I thought it was some memory corruption,
considering the lexer was seeing garbage characters. I'm a bit
disappointed my computer and github's CI didn't have the behaviour, but
oh well.
I'd like to say that this is not my fault and that there really should
be a wrapper around FILE* operations in the standard C++ library, or
that this would have been avoided had we been writing Rust, but sadly... :)
I think the patch to test is pretty easy if any of you guys want to test
it. I'll also send a public key to Mark, thank you for the offer:
---
gcc/rust/lex/rust-lex.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/rust/lex/rust-lex.h b/gcc/rust/lex/rust-lex.h
index c50f63208de..b0d7494f063 100644
--- a/gcc/rust/lex/rust-lex.h
+++ b/gcc/rust/lex/rust-lex.h
@@ -144,7 +144,7 @@ public:
/**
* Lex the contents of a string instead of a file
*/
- static Lexer lex_string (std::string input)
+ static Lexer lex_string (std::string &input)
{
// We can perform this ugly cast to a non-const char* since we're only
// *reading* the string. This would not be valid if we were doing any
--
2.35.1
This forces the string to simply be a reference and the caller to make
sure that it outlives the lexer.
If this passes the valgrind tests, I'll open up a PR with a comment
explaining the behavior and how we should think about cleaning
it up.
Moral of the story is: fmemopen(3) does not allocate memory in all
cases, RTFM
>> I can easily test any patches that you need tested.
>
>
> Grüße
> Thomas
>
>
>>> On Wed, 2 Mar 2022 at 07:21, Thomas Schwinge <thomas@codesourcery.com> wrote:
>>>>
>>>> Hi!
>>>>
>>>> On 2022-03-02T00:15:41+0100, Mark Wielaard <mark@klomp.org> wrote:
>>>>> On Tue, Mar 01, 2022 at 07:08:15PM +0000, buildbot@builder.wildebeest.org wrote:
>>>>>> The Buildbot has detected a new failure on builder gccrust-debian-arm64 while building gccrust.
>>>>>> Full details are available at:
>>>>>> https://builder.wildebeest.org/buildbot/#builders/58/builds/1710
>>>>>>
>>>>>> Buildbot URL: https://builder.wildebeest.org/buildbot/
>>>>>>
>>>>>> Worker for this Build: debian-arm64
>>>>>>
>>>>>> Build Reason: <unknown>
>>>>>> Blamelist: Arthur Cohen <arthur.cohen@embecosm.com>
>>>>>>
>>>>>> BUILD FAILED: failed compile (failure)
>>>>>
>>>>> And the same for all other builders.
>>>>
>>>> ... and me: <https://github.com/Rust-GCC/gccrs/issues/987>
>>>> "'[...]/gcc/rust/parse/rust-cfg-parser.cc:67: rust_cfg_parser_test:
>>>> FAIL: ASSERT_TRUE ((Rust::parse_cfg_option (input, key, value)))'".
>>>>
>>>>> I haven't figured out yet why the last commit caused this.
>>>>
>>>> (Same here.)
>>>>
>>>>> But it can be replicated when configuring with --enable-checking=yes
>>>>
>>>> That's strange -- isn't some '--enable-checking=[...]' actually the
>>>> default for GCC builds?
>>>>
>>>>> That causes the selftests to trigger:
>>>>
>>>> At least we can see that the GCC/Rust self-tests are executing! ;-P
>>>>
>>>>
>>>> Grüße
>>>> Thomas
>>>>
>>>>
>>>>> make[2]: Entering directory '/home/mark/build/gccrs-obj/gcc'
>>>>> /home/mark/build/gccrs-obj/./gcc/xgcc -B/home/mark/build/gccrs-obj/./gcc/ -xrs -nostdinc /dev/null -S -o /dev/null -fself-test=/home/mark/src/gccrs/gcc/testsuite/selftests
>>>>> rust1: error: unexpected character ‘1’
>>>>> rust1: error: unexpected character ‘0’
>>>>> rust1: error: unexpected character ‘0’
>>>>> rust1: error: unexpected character ‘0’
>>>>> rust1: error: unexpected character ‘1’
>>>>> rust1: error: unexpected character ‘0’
>>>>> rust1: error: unexpected character ‘0’
>>>>> rust1: error: unexpected character ‘0’
>>>>> rust1: error: unexpected character ‘e0’
>>>>> rust1: error: unexpected character ‘d3’
>>>>> rust1: error: unexpected character ‘89’
>>>>> /home/mark/src/gccrs/gcc/rust/parse/rust-cfg-parser.cc:68: rust_cfg_parser_test: FAIL: ASSERT_EQ ((key), ("key_no_value"))
>>>>> rust1: internal compiler error: in fail, at selftest.cc:47
>>>>> 0x1cf096b selftest::fail(selftest::location const&, char const*)
>>>>> /home/mark/src/gccrs/gcc/selftest.cc:47
>>>>> 0x7bb9a3 selftest::rust_cfg_parser_test()
>>>>> /home/mark/src/gccrs/gcc/rust/parse/rust-cfg-parser.cc:68
>>>>> 0x1c143b7 selftest::run_tests()
>>>>> /home/mark/src/gccrs/gcc/selftest-run-tests.cc:119
>>>>> 0xf1310b toplev::run_self_tests()
>>>>> /home/mark/src/gccrs/gcc/toplev.cc:2217
>>>>> Please submit a full bug report,
>>>>> with preprocessed source if appropriate.
>>>>> Please include the complete backtrace with any bug report.
>>>>> See <https://gcc.gnu.org/bugs/> for instructions.
>>>>> make[2]: *** [/home/mark/src/gccrs/gcc/rust/Make-lang.in:232: s-selftest-rust] Error 1
>>>>> make[2]: Leaving directory '/home/mark/build/gccrs-obj/gcc'
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Mark
>>>>>
>>>>> --
>>>>> Gcc-rust mailing list
>>>>> Gcc-rust@gcc.gnu.org
>>>>> https://gcc.gnu.org/mailman/listinfo/gcc-rust
>>>> -----------------
>>>> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
>>>> --
>>>> Gcc-rust mailing list
>>>> Gcc-rust@gcc.gnu.org
>>>> https://gcc.gnu.org/mailman/listinfo/gcc-rust
> -----------------
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Thanks a lot,
--
Arthur Cohen <arthur.cohen@embecosm.com>
Toolchain Engineer
Embecosm GmbH
Geschäftsführer: Jeremy Bennett
Niederlassung: Nürnberg
Handelsregister: HR-B 36368
www.embecosm.de
Fürther Str. 27
90429 Nürnberg
Tel.: 091 - 128 707 040
Fax: 091 - 128 707 077
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3195 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
next prev parent reply other threads:[~2022-03-02 12:05 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-01 19:08 buildbot
2022-03-01 23:15 ` Mark Wielaard
2022-03-02 7:21 ` Thomas Schwinge
2022-03-02 9:03 ` Philip Herron
2022-03-02 9:44 ` Thomas Schwinge
2022-03-02 10:05 ` Thomas Schwinge
2022-03-02 12:05 ` Arthur Cohen [this message]
2022-03-02 12:36 ` Thomas Schwinge
2022-03-02 13:31 ` Arthur Cohen
2022-03-02 10:00 ` Mark Wielaard
-- strict thread matches above, loose matches on Subject: below --
2022-03-22 12:41 buildbot
2022-03-22 13:08 ` Mark Wielaard
2022-03-22 13:09 ` Arthur Cohen
2022-03-07 9:49 buildbot
2022-03-07 9:57 ` Arthur Cohen
2022-03-07 14:23 ` Mark Wielaard
2022-03-07 14:32 ` Arthur Cohen
2022-03-07 14:42 ` Mark Wielaard
2022-03-08 14:32 ` Arthur Cohen
2022-03-06 22:01 buildbot
2022-03-06 22:20 ` Mark Wielaard
2022-03-06 22:33 ` Mark Wielaard
2022-03-07 8:54 ` Arthur Cohen
2022-02-23 11:48 buildbot
2022-02-23 10:26 buildbot
2022-02-23 10:35 ` Mark Wielaard
2022-02-23 11:26 ` Mark Wielaard
2022-02-23 23:19 ` Mark Wielaard
2022-02-18 12:11 buildbot
2022-02-18 12:48 ` dkm
2022-02-18 13:30 ` Mark Wielaard
2022-02-18 15:20 ` Thomas Fitzsimmons
2022-02-17 19:26 buildbot
2022-02-17 19:46 ` Marc
2022-02-17 21:05 ` Mark Wielaard
2022-02-17 22:03 ` Mark Wielaard
2022-02-05 16:58 buildbot
2022-02-05 17:12 ` Mark Wielaard
2022-01-29 16:20 buildbot
2022-01-29 20:23 ` Mark Wielaard
2022-01-24 12:29 buildbot
2022-01-24 12:37 ` Mark Wielaard
2022-01-24 21:30 ` Marc
2022-01-25 7:33 ` Thomas Schwinge
2022-01-25 22:42 ` Mark Wielaard
2022-01-29 20:20 ` Mark Wielaard
2022-02-03 20:55 ` Thomas Schwinge
2022-02-04 10:23 ` Mark Wielaard
2021-12-19 17:13 buildbot
2021-12-20 17:10 ` Mark Wielaard
2021-11-05 13:49 buildbot
2021-11-05 14:26 ` Mark Wielaard
2021-09-25 12:04 buildbot
2021-09-25 13:18 ` Mark Wielaard
2021-08-22 15:55 buildbot
2021-08-22 16:22 ` Mark Wielaard
2021-08-04 15:15 buildbot
2021-08-04 20:25 ` Mark Wielaard
2021-08-06 14:31 ` Philip Herron
2021-08-06 15:55 ` cohenarthur.dev
2021-08-06 23:19 ` Mark Wielaard
2021-08-08 11:52 ` Philip Herron
2021-08-06 22:39 ` Mark Wielaard
2021-08-08 11:51 ` Philip Herron
2021-08-08 12:09 ` Mark Wielaard
2021-06-18 11:06 buildbot
2021-06-18 11:31 ` Mark Wielaard
2021-06-12 23:38 buildbot
2021-06-12 23:51 ` Mark Wielaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=77b8bfab-7e29-a18c-39f8-acc033573ee1@embecosm.com \
--to=arthur.cohen@embecosm.com \
--cc=buildbot@builder.wildebeest.org \
--cc=gcc-rust@gcc.gnu.org \
--cc=mark@klomp.org \
--cc=philip.herron@embecosm.com \
--cc=thomas@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).