I ran cppcheck on a whim while trying to debug #103 and it found these possible
memory corruptions. They all seem to be buffers that were made one byte too
small (leaving out the byte for the C-string null terminator).
When we parse /proc/<pid>/* in order to populate the process struct, it isn't
necessary to try to remove any instance of "kdeinit: " anymore (IMO). Here is
why:
* If the user chooses to display full command lines (top_name_verbose = true),
then we should show full command lines without stripping useful info.
* The new basename entry already has a stripped down command. For example, if
the command line is "kdeinit4: kded4 [kdeinit]", then basename is "kded4".
* The code does not account for "kdeinit{4,5}: ", resulting in undesired
behavior, e.g. "kdeinit4: kded4 [kdeinit]" becomes "kdeinit4:".
* The code does not account for NUL separated arguments.
* The code opens /proc/<pid>/cmdline a second time, so this commit is a minor
optimization.
I think it is best to remove this code altogether. If anyone disagrees, please
comment or send me some hate mail with reasons why we should keep it. The commit
is easy enough to revert. :)
The new top_name_verbose option works in most cases, but it will fail if the
executable name contains spaces. Trying to parse command lines from
/proc/<pid>/* turned out to be quite complex due to the many edge cases. My
solution, once again, is to fall back to 1.9.x behavior. If top_name_verbose is
true, use the full command line. Otherwise, use basename.
Fixes #131.
Currently, in order to match a running process with ${if_running}, a user needs
to specify the full command line plus arguments in conky.conf. This commit keeps
that behavior and adds a fallback that is equivalent to the 1.9.x bevahior,
namely matching against the executable name contained in /proc/<pid>/stat.
This completes the fix for #121.
Since we now store a full command line for each process, a few problems are
apparent. For example, the names displayed by ${top ...} are verbose. This has
been partially addressed by the top_name_verbose option, but it is broken
whenever an executable name contains spaces. Another example is ${if_running},
which only matches the input if it exactly matches the entire command line.
This commit adds a basename (i.e. executable filename) entry to the process
struct. The intention is to store the executable filename from /proc/<pid>/stat,
which was the old 1.9.x behavior. This way, we have the best of both worlds.
Those who like the full command line can have it, and those who prefer the old
way can be satisfied too.
According to proc(5), /proc/<pid>/cmdline is supposed to have a NUL between each
argument, plus an additional NUL at the end. Instead of replacing each NUL with
a space, just replace the ones between arguments and ignore the rest.
Partial fix for #121.
lua_gettable returns an int instead of void in Lua 5.3, so provide a
backwards-compatible overload of safe_misc_trampoline to account for this.
Tested with Lua 5.2 and 5.3.
This change does not address other compilation issues related to Lua bindings
for cairo, imlib2, and rsvg.
Fixes #90 and part of #100.
Note: This may not be the correct solution, it depends on the author's intention. Maybe he wanted to keep the headers from the previous call (in other words if there are no new headers use the old ones) and didn't realize they weren't copied in the handle, in which case he'll have to save the headers instead of above.
There are 2 variants of strerror_r, GNU extension and a POSIX variant.
Use the more portable POSIX variant.
Also fix a potensial stack-use-after-return bug, instead of relying on
undefined behavoir in GNU libc implementation. The strerror_r manpage
says:
> This may be either a pointer to a string that the function stores in
> buf, or a pointer to some (immutable) static string (in which case buf
> is unused).
So it does not guarantee that it returns a pointer to some (immutable)
static string. It might return a pointer to "buf", in which case we get
a stack-use-after-return bug.
We fix this by declaring a thread local static buffer which we always
return.
Currently, state::getglobal pushes two values onto the stack: the global
environment and the requested global. For example, if you call
getglobal("conky"), the stack ends up with the following:
| ... global, conky |
The function config_setting_base::lua_set in setting.cc does not take this
behavior into account, resulting in #97.
To correct this, call replace(-2) at the end of state::getglobal where
LUA_VERSION_NUM >= 502.
Since commit 749083a, the output of ${top name <num>} contains the full
command line of each process, including arguments. While this feature can
be very useful, it changes the default behavior of Conky.
The present commit adds a new top_name_verbose option that allows the user
to toggle between basenames with no arguments (the old behavior) and full
command lines with arguments. To remain consistent with past versions of
Conky, the default value of top_name_verbose is false.
Fixes #113 (https://github.com/brndnmtthws/conky/issues/113).
get_cpu_count() is not called before trying to use cpus so conky exits with
conky: obj->data.i 1 info.cpu_count 0
conky: attempting to use more CPUs than you have!
Fixes issue #93.
If BUILD_IPV6=ON (default), but the user has disabled ipv6 support
in the kernel using the parameter ipv6.disable=1, then conky fails
to open /proc/net/if_inet6. This leads to a segfault when conky
calls fclose(file) regardless. This fix simply moves the fclose call
into the preceding if statement.
