abrt 1.0.9 detected a crash. architecture: i686 Attached file: backtrace comment: try vfork program component: coreutils executable: /bin/ls global_uuid: a49bbe83f659995944f3d5c9507c07855b510f1e kernel: 2.6.32.11-99.fc12.i686.PAE package: coreutils-7.6-9.fc12 rating: 4 reason: Process /bin/ls was killed by signal 11 (SIGSEGV) release: Fedora release 12 (Constantine) How to reproduce ----- 1. i have done program using Vfork system call. 2. 3.
Created attachment 411466 [details] File: backtrace
Thanks for report, the same could be done for every single coreutils utility ... except true and false - where it was fixed because of https://bugzilla.redhat.com/show_bug.cgi?id=537684 ;) . "set_program_name (argv[0] ? argv[0] : PROGRAM_NAME);" instead of "set_program_name (argv[0]);" in every single coreutils source file could solve the problem... Upstream maintainer stated in http://marc.info/?l=coreutils-bug&m=125832075427611&w=2 that he still haven't decided how to accomodate this. Therefore adding him to CC to check if the comment is still valid.
Thanks for the report. Actually, this *was* resolved. We addressed that problem via a change to gnulib's progname module. In newer versions of coreutils, when a program is abused in this way, it prints a diagnostic telling what you've done wrong: $ printf '%s\n' '#include <unistd.h>' 'int main(int c, char**v)' \ '{ execve (v[1], 0, 0); }' > k.c && gcc k.c && ./a.out $PWD/ls A NULL argv[0] was passed through an exec system call. zsh: abort (core dumped) ./a.out $PWD/ls [Exit 134 (ABRT)] The solution is not to pass a NULL argv to any exec-style system call.
Ah, ok, sorry for confusion, Jim ... confirmed - diagnostic is present in coreutils-8.5 (now in Rawhide) and in coreutils-8.4 (to be in F-13) ... I do not plan to backport diagnostics into F-12 at the moment - as this is misuse of execve. Closing NEXTRELEASE.