Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

preload sets errno #469

Closed
Absolucy opened this issue Jul 7, 2022 · 1 comment · Fixed by #470
Closed

preload sets errno #469

Absolucy opened this issue Jul 7, 2022 · 1 comment · Fixed by #470

Comments

@Absolucy
Copy link
Contributor

Absolucy commented Jul 7, 2022

Describe the bug
The library preloaded by bear sets errno to EINVAL, which causes strange errors in software that checks for errno in functions.

To Reproduce

#include <stdlib.h>
#include <errno.h>
#include <string.h>

int main()
{
	printf("error %i: %s\n", errno, strerror(errno));
	return 0;
}
$ bear -- ./a.out
error 22: Invalid argument

Expected behavior

$ ./a.out 
error 0: Success

Environment:

  • OS name: Linux
  • OS version: Arch Linux
  • OS architecture: x86_64
  • Bear version: 3.0.19
  • Bear install method: Arch Linux repos

Additional context
N/A, bug is completely unrelated to build systems, and can be reliably reproduced on a basic 5-line executable.

Before you send...

  • Have you read the README.md file or man bear?: Yes
  • Have you looked what other open issues Bear has?: Yes
  • Are you sure that the build works without Bear?: Yes
@rizsotto
Copy link
Owner

rizsotto commented Jul 8, 2022

thanks @Absolucy !

intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this issue Jul 25, 2023
…etline()

getline() returns -1 at EOF as well as on error. It also doesn't set
errno to 0 on success, so initialize it to 0 before using errno to check
for an error condition. See the paragraph here [1]:

  For some system calls and library functions (e.g., getpriority(2)),
  -1 is a valid return on success. In such cases, a successful return
  can be distinguished from an error return by setting errno to zero
  before the call, and then, if the call returns a status that indicates
  that an error may have occurred, checking to see if errno has a
  nonzero value.

Bear has a bug [2] that launches processes with errno set and causes the
following build failure:

 $ bear -- make LLVM=1
 ...
  LD      .tmp_vmlinux.kallsyms1
  NM      .tmp_vmlinux.kallsyms1.syms
  KSYMS   .tmp_vmlinux.kallsyms1.S
 read_symbol: Invalid argument

[1]: https://linux.die.net/man/3/errno
[2]: rizsotto/Bear#469

Fixes: 1c975da ("scripts/kallsyms: remove KSYM_NAME_LEN_BUFFER")
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: James Clark <james.clark@arm.com>
akiyks pushed a commit to akiyks/linux that referenced this issue Jul 31, 2023
…etline()

getline() returns -1 at EOF as well as on error. It also doesn't set
errno to 0 on success, so initialize it to 0 before using errno to check
for an error condition. See the paragraph here [1]:

  For some system calls and library functions (e.g., getpriority(2)),
  -1 is a valid return on success. In such cases, a successful return
  can be distinguished from an error return by setting errno to zero
  before the call, and then, if the call returns a status that indicates
  that an error may have occurred, checking to see if errno has a
  nonzero value.

Bear has a bug [2] that launches processes with errno set and causes the
following build failure:

 $ bear -- make LLVM=1
 ...
  LD      .tmp_vmlinux.kallsyms1
  NM      .tmp_vmlinux.kallsyms1.syms
  KSYMS   .tmp_vmlinux.kallsyms1.S
 read_symbol: Invalid argument

[1]: https://linux.die.net/man/3/errno
[2]: rizsotto/Bear#469

Fixes: 1c975da ("scripts/kallsyms: remove KSYM_NAME_LEN_BUFFER")
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: James Clark <james.clark@arm.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants