Sample reproducer:

$ sleep 600 &
$ PID=$!
$ valgrind ps -e -q $PID
...
==66579== Invalid read of size 4
==66579==    at 0x4E43E0E: listed_nextpid (readproc.c:1264)
==66579==    by 0x4E46866: readproc (readproc.c:1301)
==66579==    by 0x112E80: simple_spew (display.c:373)
==66579==    by 0x112E80: main (display.c:673)
==66579==  Address 0x76971c4 is 0 bytes after a block of size 4 alloc'd
==66579==    at 0x4C30BEB: malloc (vg_replace_malloc.c:299)
==66579==    by 0x112F82: simple_spew (display.c:355)
==66579==    by 0x112F82: main (display.c:673)
...

  Cause of the problem is the two bugs below:

ps/display.c:simple_spew()
...
  pidlist = NULL;
...
    pidlist = (pid_t*) malloc(selection_list->n * sizeof(pid_t));
    <<< BUG 1 >>>
...
    for (i = 0; i < selection_list->n; i++) {
      pidlist[i] = selection_list->u[selection_list->n-i-1].pid;
    }
    <<<< BUG 2 >>>
...
  ptp = openproc(flags, pidlist);

BUG 1 means it should allocate one extra entry.
BUG 2 means it should set the last entry to zero.

  The problem happens in:

proc/readproc.c:openproc()
...
    va_start(ap, flags);
    if (flags & PROC_PID)
        PT->pids = va_arg(ap, pid_t*);
...

in the above, the PT->pids list does not end with an explicit zero.
The problem manifests in:

proc/readproc.c:listed_nextpid()
...
  pid_t tgid = *(PT->pids)++;
  if(likely(tgid)){
    snprintf(path, PROCPATHLEN, "/proc/%d", tgid);
    p->tgid = tgid;
    p->tid = tgid;  // they match for leaders
  }
  return tgid;
...

Causing undefined behaviour in output. Most times it is just an
invalid read and by accident, correct output.