public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug build/31316] Fails test misc/tst-dirname "Didn't expect signal from child: got `Illegal instruction'" on non SSE CPUs Date: Tue, 30 Jan 2024 11:55:54 +0000 [thread overview] Message-ID: <bug-31316-131-j2BzwP2gUR@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-31316-131@http.sourceware.org/bugzilla/> https://sourceware.org/bugzilla/show_bug.cgi?id=31316 Florian Weimer <fweimer at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fweimer at redhat dot com --- Comment #1 from Florian Weimer <fweimer at redhat dot com> --- The instruction stream does not make sense. Running this: “ import base64 data="""8d 70 08 f7 c6 0f 00 00 00 0f 85 20 0a 00 00 8d 5c 97 04 65 a1 0c 00 00 00 85 c0 0f 85 46 04 00 00 8b 4c 24 18 89 f0 c1 e8 0c 8b 79 08 8b 4c 24 14 31 f8 89 41 04 8b 44 24 18 8b 40 04 89 44 24 """.replace(' ', '').replace('\n', '') with open('f', 'wb') as out: out.write(base64.b16decode(data, casefold=True)) ” And: objdump -b binary -m i386 -D f gives: 0: 8d 70 08 lea 0x8(%eax),%esi 3: f7 c6 0f 00 00 00 test $0xf,%esi 9: 0f 85 20 0a 00 00 jne 0xa2f f: 8d 5c 97 04 lea 0x4(%edi,%edx,4),%ebx 13: 65 a1 0c 00 00 00 mov %gs:0xc,%eax 19: 85 c0 test %eax,%eax 1b: 0f 85 46 04 00 00 jne 0x467 21: 8b 4c 24 18 mov 0x18(%esp),%ecx 25: 89 f0 mov %esi,%eax 27: c1 e8 0c shr $0xc,%eax 2a: 8b 79 08 mov 0x8(%ecx),%edi 2d: 8b 4c 24 14 mov 0x14(%esp),%ecx 31: 31 f8 xor %edi,%eax 33: 89 41 04 mov %eax,0x4(%ecx) 36: 8b 44 24 18 mov 0x18(%esp),%eax 3a: 8b 40 04 mov 0x4(%eax),%eax 3d: 89 .byte 0x89 3e: 44 inc %esp 3f: 24 .byte 0x24 The fault is at offset 0x2a, which is as far as I can see a perfectly fine i386 instruction. It's also not in a string function, the instruction sequence involving %gs is related to a single-thread optimization. The tail involving inc %esp is also really dubious. Could you obtain a backtrace using GDB, possibly from a coredump? -- You are receiving this mail because: You are on the CC list for the bug.
next prev parent reply other threads:[~2024-01-30 11:55 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-01-30 3:05 [Bug build/31316] New: " immoloism at googlemail dot com 2024-01-30 3:06 ` [Bug build/31316] " immoloism at googlemail dot com 2024-01-30 3:19 ` immoloism at googlemail dot com 2024-01-30 3:22 ` immoloism at googlemail dot com 2024-01-30 11:55 ` fweimer at redhat dot com [this message] 2024-02-13 17:21 ` sam at gentoo dot org 2024-02-13 17:25 ` fweimer at redhat dot com 2024-02-13 17:27 ` sam at gentoo dot org 2024-02-13 17:28 ` sam at gentoo dot org 2024-02-13 17:41 ` sam at gentoo dot org 2024-02-13 17:42 ` sam at gentoo dot org 2024-02-13 17:48 ` fweimer at redhat dot com 2024-02-15 14:05 ` sam at gentoo dot org 2024-02-15 14:50 ` fweimer at redhat dot com 2024-02-16 6:42 ` fweimer at redhat dot com
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=bug-31316-131-j2BzwP2gUR@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /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: linkBe 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).