I think I've figured it out. With the following patch I don't see the
unexpected behaviour anymore:
--- a/src/killall5.c
+++ b/src/killall5.c
@@ -662,6 +662,7 @@ int readproc()
/* Try to stat the executable. */
snprintf(path, sizeof(path), "/proc/%s/exe", d->d_name);
p->pathname = (char *)xmalloc(PATH_MAX);
+ memset(p->pathname, 0, PATH_MAX);
if (readlink(path, p->pathname, PATH_MAX) == -1) {
p->pathname = NULL;
}
This patch gets rid of this uninitialised value warning I saw in valgrind:
==4158== Conditional jump or move depends on uninitialised value(s)
==4158== at 0x484748D: strcmp (vg_replace_strmem.c:924)
==4158== by 0x10A64F: pidof (killall5.c:797)
==4158== by 0x10B2EE: main_pidof (killall5.c:1031)
==4158== by 0x109700: main (killall5.c:1108)
==4158== Uninitialised value was created by a heap allocation
==4158== at 0x4840660: malloc (vg_replace_malloc.c:381)
==4158== by 0x10AD51: xmalloc (killall5.c:170)
==4158== by 0x10AD51: readproc (killall5.c:664)
==4158== by 0x10B2A0: main_pidof (killall5.c:1028)
==4158== by 0x109700: main (killall5.c:1108)
I compiled the killall5 binary with:
CFLAGS="-O2 -ggdb" make killall5
Am 23.03.23 um 16:25 schrieb Jesse Smith:
On 2023-03-23 12:04 p.m., Markus Fischer wrote:
I could also reproduce it with emacs. I've used emacs-gtk to avoid the
symlink.
```shell 1
$ emacs-gtk -nw -fn helvetica
```
```shell 2
$ ./pidof emacs-gtk
24727
$ ./pidof $(which emacs-gtk)
$ ls -l $(which emacs-gtk)
-rwxr-xr-x 1 root root 5294300 Mar 14 21:30 /usr/bin/emacs-gtk
```
This is interesting. Is there anything else you can share that might
shed light on why this happens while I can't get the same results? You
mentioned you're using two separate shells. Are they with the same user
account? Is there any PID hiding feature of Debian enabled? Does it
still happen if you run "pidof -z $(which emacs-gtk)"?
