Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
I am ashamed to say, /dev/null being a regular file was the source of the problem. Actually this was one of the very first ideas I had and I tested against it in multiple ways. I ran: echo asdf > /dev/null ; cat /dev/null and cat /dev/null several times, always returning empty. It must have been freak chance. I mistook the output of "file /dev/null" to name a /dev/null empty device rather than an empty file of that name. Also this has happened to me a couple of times before, and in the past it always caused very obvious problems on the entire system. I am sorry for the inconvenience. Best regards, Mathias On 1/22/21 3:09 PM, Chet Ramey wrote: On 1/22/21 2:53 AM, Eduardo A. Bustamante López wrote: - Notice that the value returned by `fstat(0, ...)' indicates that /dev/null in your system is a *regular* file (it should be `st_mode=S_IFCHR|0666', but instead it is `st_mode=S_IFCHR|0666'). It also indicates that its size is 73 bytes (`st_size=73'). - Notice that `cat' reads from file descriptor 0 (i.e. /dev/null), and the return value is a string of 73 bytes in length. - `cat' then writes that string out to `./config.status' 73 happens to be the length of the string that has been causing issues for you: $ echo "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));" | wc -c 73 This is a first-class observation.
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
i had similiar where i used exec socat for file transfer daemon and client, and sometimes codes of the code or cmds appeared in output, till i removed the exec On Fri, Jan 22, 2021, 15:15 Chet Ramey wrote: > On 1/22/21 2:53 AM, Eduardo A. Bustamante López wrote: > > > - Notice that the value returned by `fstat(0, ...)' indicates that > /dev/null in your system is a *regular* file (it should be > `st_mode=S_IFCHR|0666', but instead it is `st_mode=S_IFCHR|0666'). It also > indicates that its size is 73 bytes (`st_size=73'). > > - Notice that `cat' reads from file descriptor 0 (i.e. /dev/null), and > the return value is a string of 73 bytes in length. > > - `cat' then writes that string out to `./config.status' > > > > 73 happens to be the length of the string that has been causing issues > for you: > > > >$ echo "extern void free (void *__ptr) __attribute__ ((__nothrow__ , > __leaf__));" | wc -c > >73 > > This is a first-class observation. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ > >
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
On 1/22/21 2:53 AM, Eduardo A. Bustamante López wrote: - Notice that the value returned by `fstat(0, ...)' indicates that /dev/null in your system is a *regular* file (it should be `st_mode=S_IFCHR|0666', but instead it is `st_mode=S_IFCHR|0666'). It also indicates that its size is 73 bytes (`st_size=73'). - Notice that `cat' reads from file descriptor 0 (i.e. /dev/null), and the return value is a string of 73 bytes in length. - `cat' then writes that string out to `./config.status' 73 happens to be the length of the string that has been causing issues for you: $ echo "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));" | wc -c 73 This is a first-class observation. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
Still strange that downgrading helps shouldnt touch /dev/null .
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
22 Ocak 2021 Cuma tarihinde Eduardo A. Bustamante López yazdı: > > - Notice that the value returned by `fstat(0, ...)' indicates that > /dev/null in your system is a *regular* file (it should be > `st_mode=S_IFCHR|0666', but instead it is `st_mode=S_IFCHR|0666'). It also > indicates that its size is 73 bytes (`st_size=73'). > - Notice that `cat' reads from file descriptor 0 (i.e. /dev/null), and the > return value is a string of 73 bytes in length. > - `cat' then writes that string out to `./config.status' > > 73 happens to be the length of the string that has been causing issues for > you: > > $ echo "extern void free (void *__ptr) __attribute__ ((__nothrow__ , > __leaf__));" | wc -c > 73 > Hilarious. I bet at some point, someone thought moving a file to /dev/null would have the same effect as removing it... -- Oğuz
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
On Fri, Jan 22, 2021 at 8:53 AM Eduardo A. Bustamante López wrote: > These are worth highlighting: > > - Notice that the value returned by `fstat(0, ...)' indicates that /dev/null > in your system is a *regular* file (it should be `st_mode=S_IFCHR|0666', but > instead it is `st_mode=S_IFCHR|0666'). It also indicates that its size is 73 > bytes (`st_size=73'). I believe for the last part Eduardo meant to write: (it should be `st_mode=S_IFCHR|0666', but instead it is `st_mode=S_IFREG|0666')
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
On Fri, Jan 22, 2021 at 05:05:31AM +0100, Mathias Steiger wrote:
>
> Here is the strace output.
>
> https://filebin.net/9auqyreezma08z12/bug_bash.tar.gz?t=3bjx4xpd
>
> It is very excessive due to the nature of Autoconf and I couldn't make a lot
> of sense of it.
>
>
> When I downgraded the package from bash-5.1.004-1 to bash-5.0.018-2 the bug
> disappeared.
This trace file is quite interesting (redacted for brevity):
$ cat ./strace_if-statement_removed/strace_second.1243868
(...)
openat(AT_FDCWD, "./config.status", O_WRONLY|O_CREAT|O_APPEND, 0666) = 8
dup2(8, 1) = 1
close(8)= 0
openat(AT_FDCWD, "/dev/null", O_RDONLY) = 8
dup2(8, 0) = 0
close(8)= 0
execve("/bin/cat", ["cat"], [(...)]) = 0
(...)
fstat(1, {st_dev=makedev(0xfe, 0x3), st_ino=42548069, st_mode=S_IFREG|0775,
st_nlink=1, st_uid=1006, st_gid=0, st_blksize=4096, st_blocks=32,
st_size=16357, st_atime=1611282495 /* 2021-01-22T03:28:15.296486563+0100 */,
st_atime_nsec=296486563, st_mtime=1611282560 /*
2021-01-22T03:29:20.712747829+0100 */, st_mtime_nsec=712747829,
st_ctime=1611282560 /* 2021-01-22T03:29:20.712747829+0100 */,
st_ctime_nsec=712747829}) = 0
fstat(0, {st_dev=makedev(0, 0x5), st_ino=1728, st_mode=S_IFREG|0666,
st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=73,
st_atime=1611282495 /* 2021-01-22T03:28:15.243153560+0100 */,
st_atime_nsec=243153560, st_mtime=1611282549 /*
2021-01-22T03:29:09.822815317+0100 */, st_mtime_nsec=822815317,
st_ctime=1611282549 /* 2021-01-22T03:29:09.822815317+0100 */,
st_ctime_nsec=822815317}) = 0
(...)
read(0, "extern void free (void *__ptr) __attribute__ ((__nothrow__ ,
__leaf__));\n", 131072) = 73
write(1, "extern void free (void *__ptr) __attribute__ ((__nothrow__ ,
__leaf__));\n", 73) = 73
read(0, "", 131072) = 0
(...)
This is in essence:
cat ./config.status
These are worth highlighting:
- Notice that the value returned by `fstat(0, ...)' indicates that /dev/null in
your system is a *regular* file (it should be `st_mode=S_IFCHR|0666', but
instead it is `st_mode=S_IFCHR|0666'). It also indicates that its size is 73
bytes (`st_size=73').
- Notice that `cat' reads from file descriptor 0 (i.e. /dev/null), and the
return value is a string of 73 bytes in length.
- `cat' then writes that string out to `./config.status'
73 happens to be the length of the string that has been causing issues for you:
$ echo "extern void free (void *__ptr) __attribute__ ((__nothrow__ ,
__leaf__));" | wc -c
73
Can you run:
stat /dev/null
And share with us what you get?
This is how it should look like:
$ stat /dev/null
File: /dev/null
Size: 0 Blocks: 0 IO Block: 4096 character special
file
Device: 5h/5d Inode: 4 Links: 1 Device type: 1,3
Access: (0666/crw-rw-rw-) Uid: (0/root) Gid: (0/root)
Access: 2021-01-09 15:28:48.589801534 -0800
Modify: 2021-01-09 15:28:48.589801534 -0800
Change: 2021-01-09 15:28:48.589801534 -0800
Birth: -
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
I will write a report to automake. On 1/22/21 4:01 AM, Chet Ramey wrote: This is why I advised you to report it to bug-autoconf. They're more familiar with the code generator and what problems might result from it.
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
It is /bin/sh which is a symlink to bash on Archlinux. On 1/22/21 12:27 AM, Eduardo Bustamante wrote: Greg pointed out earlier that the construct you're trying to use doesn't work well when the shell is not Bash. Are you 100% confident that it is /bin/bash that is running the script and not /bin/sh (and thus maybe something like Dash?). And keep in mind that even Bash running as /bin/sh is not quite the same as Bash running as /bin/bash.
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
Here is the strace output. https://filebin.net/9auqyreezma08z12/bug_bash.tar.gz?t=3bjx4xpd It is very excessive due to the nature of Autoconf and I couldn't make a lot of sense of it. When I downgraded the package from bash-5.1.004-1 to bash-5.0.018-2 the bug disappeared. On 1/22/21 12:27 AM, Eduardo Bustamante wrote: On Thu, Jan 21, 2021 at 2:07 PM Mathias Steiger wrote: As such bugs are likely related to buffer issues, maybe even in underlying APIs, and since they only surface after very lengthy mysterious sequences of commands - often just on single specific system installations - I wouldn't know how you can reproduce this in a test. Maybe you have specific testing frameworks for this, that would reduce the whole script to more basic components and which schematically remove or add complexity until the nature of the bug becomes more apparent? This seems to call for a specialist who is able to follow the problem into a far lower level of abstraction. As it stands now, I don't see how there is no way how this kind of execution can make any sense from a scripting POV. Of course in a giant script, all sorts of random things might happen. But this is not one of them. You could run the script through "strace" or a similar command to see what's writing that output and when. We could use that log output to confirm that it is indeed Bash that is writing this out-of-order and to a file descriptor that it shouldn't. Greg pointed out earlier that the construct you're trying to use doesn't work well when the shell is not Bash. Are you 100% confident that it is /bin/bash that is running the script and not /bin/sh (and thus maybe something like Dash?). And keep in mind that even Bash running as /bin/sh is not quite the same as Bash running as /bin/bash.
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
Thanks for your reply. My report maybe did contain a lot of too tightly
packed information. I try to clarify:
The git repository is the official one of Libreelec (a Linux
distribution). Naturally it has to download packages.
I did in fact quote an brief excerpt of the wrongfully inserted line two
times (with context where it is inserted). I made that clear by
indentation, a colon and also the context. When I was speaking of a
"diff" command inserting it's output somewhere else, you can see that I
did in fact quote "diff" formatted output afterwards as marked. It might
be confusing, because it might look a bit like I was using "diff" to
quote the inserted line instead.
When I was speaking of removing "the line", I was referring to the only
line I explicitly mentioned by line number and also the only line
mentioned that has a corresponding "if" statement. It is of course hard
to follow this, if you do not open and look at the mentioned file at the
same time.
By "silenced command output" I was simply referring to what is happening
in "the line", i.e. a command having its output directed at >& /dev/null.
I don't understand the rest of the paragraph you wrote.
In my mind, I have found an impossible execution: a "silenced command"
outputs to a file it shouldn't output into.
My knowledge of bash is not perfect, but I don't believe this should or
can ever happen. Unless of course you wrote another script to
specifically remove the redirection to /dev/null and then you executed
that altered script.
How would it only "appear to be silenced"? Can you somehow resurrect
output directed at /dev/null? I guess anything is possible if you made a
lot of effort to do it, but this doesn't seem likely to me in an
Autoconfig script. Especially considering the insertion is so random and
it doesn't happen with previous bash versions.
From what I can tell, there is no further need to dissect the rest of
the script to know that this is a bug in bash, because realistically
this can never make sense as it is.
In my limited knowledge, it looks to me like some pointer address
overflowed - due to the length and complexity of the script - and then
it just reads from some arbitrary old buffer.
On 1/21/21 10:27 PM, Mathias Steiger wrote:
{if echo "27ac5e2f757302" >& /dev/null; then echo "yes"; else echo
"no"; fi } > output
and then the file "output" would contain:
"extern void free (void *__ptr) __attribute__ ((__nothrow__ ,
__leaf__)); 27ac5e2f757302 yes"
This is more or less what is happening here.
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
On 1/21/21 5:07 PM, Mathias Steiger wrote: As such bugs are likely related to buffer issues, maybe even in underlying APIs, and since they only surface after very lengthy mysterious sequences of commands - often just on single specific system installations - I wouldn't know how you can reproduce this in a test. And that's the problem. While the behavior you're seeing may be related to some `buffer issue', it's just as likely that there's some issue with how autoconf-generated scripts manipulate file descriptors or that your script interacts badly in some other way with what autoconf generates. But without a way to reproduce it independently, there's no way to tell whether it's a bug separate from autoconf. Maybe you have specific testing frameworks for this, that would reduce the whole script to more basic components and which schematically remove or add complexity until the nature of the bug becomes more apparent? This is why I advised you to report it to bug-autoconf. They're more familiar with the code generator and what problems might result from it. Of course in a giant script, all sorts of random things might happen. But this is not one of them. Maybe. Maybe not. You just don't have enough information to say. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
You could improve this bug report. A few pointers: Mathias Steiger writes: > Repeat-By: > > git clone https://github.com/LibreELEC/LibreELEC.tv > cd LibreELEC.tv > ARCH=aarch64 PROJECT=Amlogic DEVICE=AMLGX ./scripts/build linux I attempted to follow this, but the output I got was: $ ARCH=aarch64 PROJECT=Amlogic DEVICE=AMLGX no_proxy ./scripts/build linux GET linux (archive) Usage: wget [OPTION]... [URL]... Try `wget --help' for more options. Usage: wget [OPTION]... [URL]... Try `wget --help' for more options. Usage: wget [OPTION]... [URL]... [a dozen or more times] Does your build process actually make external web fetches? You really need to warn people about that if you are presenting a recipe for duplicating a bug. > -> the build fails after a minute in the Autoconfig step due to > wrongful insertion of silenced command output into file config.status at > line 533 > In: build.LibreELEC-AMLGX.aarch64-9.80-devel/build/ccache-3.7.12/configure > Go to line 6532: if diff "$cache_file" confcache >/dev/null 2>&1; then > :; else > Hint: $cache_file is always /dev/null , hence the if-statement will > evaluate false I understand that a line appears in config.status that you believe is incorrect, but you don't quote what the line is (preferably with some context around it). You assert that it is "silenced command output", but you don't actually know that (without dissecting the script you're running), only that it *appears* to be silenced command output. If you've genuinely tracked down how it got there, you should explain your reasoning in detail. > This diff command is the source of the insertion in > build.LibreELEC-AMLGX.aarch64-9.80-devel/build/ccache-3.7.12/config.status : > 0a1,97: > > # This file is a shell script that caches the results of > configure > > # tests run on this system so they can be shared between > configure > ... > Remove the line and the corresponding "fi" that closes the if-statement > -> script inserts "extern void free ..." instead into > ./config.status at line 533 You say "remove the line" but it isn't clear what line you are referring to. Dale
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
On Thu, Jan 21, 2021 at 2:07 PM Mathias Steiger wrote: > > > As such bugs are likely related to buffer issues, maybe even in > underlying APIs, and since they only surface after very lengthy > mysterious sequences of commands - often just on single specific system > installations - I wouldn't know how you can reproduce this in a test. > > Maybe you have specific testing frameworks for this, that would reduce > the whole script to more basic components and which schematically remove > or add complexity until the nature of the bug becomes more apparent? > > This seems to call for a specialist who is able to follow the problem > into a far lower level of abstraction. > > As it stands now, I don't see how there is no way how this kind of > execution can make any sense from a scripting POV. > > Of course in a giant script, all sorts of random things might happen. > But this is not one of them. You could run the script through "strace" or a similar command to see what's writing that output and when. We could use that log output to confirm that it is indeed Bash that is writing this out-of-order and to a file descriptor that it shouldn't. Greg pointed out earlier that the construct you're trying to use doesn't work well when the shell is not Bash. Are you 100% confident that it is /bin/bash that is running the script and not /bin/sh (and thus maybe something like Dash?). And keep in mind that even Bash running as /bin/sh is not quite the same as Bash running as /bin/bash.
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
As such bugs are likely related to buffer issues, maybe even in
underlying APIs, and since they only surface after very lengthy
mysterious sequences of commands - often just on single specific system
installations - I wouldn't know how you can reproduce this in a test.
Maybe you have specific testing frameworks for this, that would reduce
the whole script to more basic components and which schematically remove
or add complexity until the nature of the bug becomes more apparent?
This seems to call for a specialist who is able to follow the problem
into a far lower level of abstraction.
As it stands now, I don't see how there is no way how this kind of
execution can make any sense from a scripting POV.
Of course in a giant script, all sorts of random things might happen.
But this is not one of them.
On 1/21/21 10:38 PM, Chet Ramey wrote:
On 1/21/21 4:27 PM, Mathias Steiger wrote:
No.
If you read the the rest of the bug report, it might become clearer
to you.
Suppose I wrote a simple script:
{if echo "27ac5e2f757302" >& /dev/null; then echo "yes"; else
echo "no"; fi } > output
Suppose you did.
I did, after correcting the syntax errors in yours, and couldn't
reproduce
the problem. So if you can extract a script that exhibits the problem
from
the rest of the autoconf framework, I'll be glad to see if it
demonstrates
a bug in bash.
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
On 1/21/21 4:27 PM, Mathias Steiger wrote:
No.
If you read the the rest of the bug report, it might become clearer to you.
Suppose I wrote a simple script:
{if echo "27ac5e2f757302" >& /dev/null; then echo "yes"; else echo
"no"; fi } > output
Suppose you did.
I did, after correcting the syntax errors in yours, and couldn't reproduce
the problem. So if you can extract a script that exhibits the problem from
the rest of the autoconf framework, I'll be glad to see if it demonstrates
a bug in bash.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
On Thu, Jan 21, 2021 at 10:27:54PM +0100, Mathias Steiger wrote:
> Suppose I wrote a simple script:
>
> {if echo "27ac5e2f757302" >& /dev/null; then echo "yes"; else echo "no";
> fi } > output
I count at least 3 bugs here, or 4 if you run this from something that
works around the exec format error by running sh rather than bash.
If this is supposed to be an actual script, then you need a shebang.
That's number one.
If you're going to use curly braces to turn the compound "if" command into
a command group, then you need a space after the first brace (that's two),
and you need a newline or semicolon or other command terminator before
the second brace (that's three). Of course, you could fix both of those
by simply removing the curly braces entirely.
Finally, if you're writing this as an sh script, you cannot use the >&
operator for redirection. That's a bashism. That's number four, if
the missing shebang is #!/bin/sh. If the missing shebang invokes bash,
then the >& operator is permitted, but I still wouldn't advise it.
When reporting a bug and showing an example script, it's best if the
example script actually *runs*, and ideally, produces the actual results
that you are reporting as a bug.
Just typing random malformed commands into an email as an "example"
does not help anyone.
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
On Thu, Jan 21, 2021 at 1:32 PM Eduardo Bustamante wrote:
>
> On Thu, Jan 21, 2021 at 1:28 PM Mathias Steiger
> wrote:
> >
> >
> > No.
> >
> > If you read the the rest of the bug report, it might become clearer to you.
> >
> >
> > Suppose I wrote a simple script:
> >
> > {if echo "27ac5e2f757302" >& /dev/null; then echo "yes"; else echo
> > "no"; fi } > output
>
> Did you mean:
> echo "27ac5e2f757302" &> /dev/null;
>
> Instead?
>
> `>&` is not the same as `&>`
Actually, don't mind me. I'm wrong. I should've checked the manual first.
Sorry about the noise.
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
On Thu, Jan 21, 2021 at 1:28 PM Mathias Steiger
wrote:
>
>
> No.
>
> If you read the the rest of the bug report, it might become clearer to you.
>
>
> Suppose I wrote a simple script:
>
> {if echo "27ac5e2f757302" >& /dev/null; then echo "yes"; else echo
> "no"; fi } > output
Did you mean:
echo "27ac5e2f757302" &> /dev/null;
Instead?
`>&` is not the same as `&>`
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
No.
If you read the the rest of the bug report, it might become clearer to you.
Suppose I wrote a simple script:
{if echo "27ac5e2f757302" >& /dev/null; then echo "yes"; else echo
"no"; fi } > output
and then the file "output" would contain:
"extern void free (void *__ptr) __attribute__ ((__nothrow__ ,
__leaf__)); 27ac5e2f757302 yes"
This is more or less what is happening here.
Do you believe that could be an error in my script? If yes, how so?
How could the word "27ac5e2f757302" possibly end up in the file "output"?
Where does the mysterious line "extern void free (void *__ptr)
__attribute__ ((__nothrow__ , __leaf__));" come from? A line that is not
contained in the script or the rest of the code.
On 1/21/21 8:19 PM, Chet Ramey wrote:
On 1/21/21 1:11 PM, Mathias Steiger wrote:
Bash Version: 5.1 (Archlinux: core/bash 5.1.004-1)
Patch Level: 4
Release Status: release
Description:
An Autoconf configure script does fail, because some file it
generated does unexpectedly contain output from some command it
called in an if-statement that had output directed to >& /dev/null .
Various alterations to the script do produce strange outcomes.
Shouldn't you report this to bug-autoconf?
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
On 1/21/21 1:11 PM, Mathias Steiger wrote: Bash Version: 5.1 (Archlinux: core/bash 5.1.004-1) Patch Level: 4 Release Status: release Description: An Autoconf configure script does fail, because some file it generated does unexpectedly contain output from some command it called in an if-statement that had output directed to >& /dev/null . Various alterations to the script do produce strange outcomes. Shouldn't you report this to bug-autoconf? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
From: l0rd
To: bug-bash@gnu.org
Subject: obscure bug "extern void free (void *__ptr) __attribute__
((__nothrow__ , __leaf__));"
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin'
-DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc'
-DSYS_BASH_LOGOUT='/etc/bash.bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS
uname output: Linux C1MPAQ 5.10.7-arch1-1 #1 SMP PREEMPT Wed, 13 Jan
2021 12:02:01 + x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1 (Archlinux: core/bash 5.1.004-1)
Patch Level: 4
Release Status: release
Description:
An Autoconf configure script does fail, because some file it generated
does unexpectedly contain output from some command it called in an
if-statement that had output directed to >& /dev/null . Various
alterations to the script do produce strange outcomes. Sometimes it
avoids the bug, sometimes it will result in the line "extern void free
(void *__ptr) __attribute__ ((__nothrow__ , __leaf__));" to be inserted
into the file in addition to the behavior. This line is seemingly in
some cases also be generated by the command itself that generated the
misplaced output, which suggests that the bug is not in bash but some
API bash is written in.
Repeat-By:
git clone https://github.com/LibreELEC/LibreELEC.tv
cd LibreELEC.tv
ARCH=aarch64 PROJECT=Amlogic DEVICE=AMLGX ./scripts/build linux
-> the build fails after a minute in the Autoconfig step due to
wrongful insertion of silenced command output into file config.status at
line 533
In: build.LibreELEC-AMLGX.aarch64-9.80-devel/build/ccache-3.7.12/configure
Go to line 6532: if diff "$cache_file" confcache >/dev/null 2>&1; then
:; else
Hint: $cache_file is always /dev/null , hence the if-statement will
evaluate false
This diff command is the source of the insertion in
build.LibreELEC-AMLGX.aarch64-9.80-devel/build/ccache-3.7.12/config.status :
0a1,97:
> # This file is a shell script that caches the results of
configure
> # tests run on this system so they can be shared between
configure
...
Remove the line and the corresponding "fi" that closes the if-statement
-> script inserts "extern void free ..." instead into
./config.status at line 533
Replace line with: if diff "$cache_file" confcache >& /tmp/nothing; then
:; else
-> script inserts not only "extern void free ..." in config.status,
but also the following into /tmp/nothing at the top in addition to the
output:
1c1,97
< extern void free (void *__ptr) __attribute__ ((__nothrow__ ,
__leaf__));
---
> # This file is a shell script that caches the results of
configure
...
Replace line with if cat /tmp/nothing >& /dev/null; then :; else
-> script inserts content of /tmp/nothing into ./config.status at
line 533
Replace line with if false; then :; else # or other random commands
-> script works
Content of /tmp/nothing (all characters are exact part of the file):
1c1,97
< extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));
---
> # This file is a shell script that caches the results of configure
> # tests run on this system so they can be shared between configure
> # scripts and configure runs, see configure's option --config-cache.
> # It is not useful on other systems. If it contains results you don't
> # want to keep, you may remove or edit it.
> #
> # config.status only pays attention to the cache file if you give it
> # the --recheck option to rerun configure.
> #
> # `ac_cv_env_foo' variables (set or unset) will be overridden when
> # loading this file, other *unset* `ac_cv_foo' will be assigned the
> # following values.
>
> ac_cv_build=${ac_cv_build=x86_64-pc-linux-gnu}
> ac_cv_c_bigendian=${ac_cv_c_bigendian=no}
> ac_cv_c_compiler_clang=${ac_cv_c_compiler_clang=no}
> ac_cv_c_compiler_gnu=${ac_cv_c_compiler_gnu=yes}
> ac_cv_c_extern_inline=${ac_cv_c_extern_inline=no}
> ac_cv_c_inline=${ac_cv_c_inline=inline}
> ac_cv_env_CC_set=set
> ac_cv_env_CC_value=/bin/gcc
> ac_cv_env_CFLAGS_set=set
> ac_cv_env_CFLAGS_value='-march=native -O2 -Wall -pipe
-I/home/l0rd/LibreELEC.tv/build.LibreELEC-AMLGX.aarch64-9.80-devel/toolchain/include
-Wno-format-security'
> ac_cv_env_CPPFLAGS_set=set
> ac_cv_env_CPPFLAGS_value=
> ac_cv_env_CPP_set=set
> ac_cv_env_CPP_value=cpp
> ac_cv_env_LDFLAGS_set=set
>
ac_cv_env_LDFLAGS_value='-Wl,-rpath,/home/l0rd/LibreELEC.tv/build.LibreELEC-AMLGX.aarch64-9.80-devel/toolchain/lib
-L/home/l0rd/LibreELEC.tv/build.LibreELEC-AMLGX.aarch64-9.80-devel/toolchain/lib'
> ac_cv_env_LIB
