Fix a drawin crash, a drawin memory leak and a wallpaper error.

[Elv13]

I doubt anybody ever noticed this, but it existed.

[codecov]

Codecov Report

Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (cb72c0a) 91.01% compared to head (3fa9c66) 91.01%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #3880   +/-   ##
=======================================
  Coverage   91.01%   91.01%           
=======================================
  Files         901      902    +1     
  Lines       57566    57622   +56     
=======================================
+ Hits        52392    52447   +55     
- Misses       5174     5175    +1     

Flag	Coverage Δ
gcov	91.01% <95.31%> (+<0.01%)	⬆️
luacov	93.72% <94.91%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
lib/wibox/drawable.lua	98.88% <100.00%> (+<0.01%)	⬆️
objects/drawable.c	100.00% <100.00%> (ø)
objects/drawin.c	88.00% <100.00%> (+0.04%)	⬆️
tests/test-leaks-wibox.lua	100.00% <100.00%> (ø)
lib/wibox/init.lua	94.49% <72.72%> (-0.34%)	⬇️

... and 2 files with indirect coverage changes

[actionless]

i think it was actually some reports about weird un- investigated/confirmed leaks

and myself sometimes notice some leakage on awesome proc but i'm not sure how to reproduce that - so neither can tell for sure if they're gone with this PR

but seeing the test gives a good feeling about this, even if it's not addressing aforementioned leaks

[sclu1034]

and myself sometimes notice some leakage on awesome proc

Confirmed leakage, as in something like Valgrind confirmed that the address was dropped without a free()? Because merely observing a slow increase in memory usage over time via system monitoring is not a confirmation of a leak.

More likely, it would be the same issue as everything else reported as an alleged leak, including the 3-4 issues that are still open:

Lua doesn't have the facilities to notify its GC of how big a memory region in a pointer is. I.e. if you have a userdata that contains a pointer to a big memory chunk (such as a Cairo surface pointing to image data), Lua only knows about the size of the userdata struct, which would be 64 bit for the pointer. Lua doesn't know, and cannot be told about, the kilo- or megabytes of data that the pointer actually contains, because they were not allocated by Lua.
You'd have to do all memory allocation through lua_newuserdata, but that's not compatible with the internal memory management of GLib and other libraries.

Example:
With the default settings for the garbage collector, the allocated memory (as known to the GC) needs to double for the next cycle to start.
If the GC thinks that the current usage after the last cycle is 50 MB, then it would take ~800000 of those 64 bit userdata values to double the usage and trigger the next cycle. But if those values each point to 512 KB of memory, you'd also have about 400 MB that the GC isn't aware of, bringing the total to 500 MB.

This is easily verifiable by adding a GIdleSource, or a short timer, that forces full GC cycles (collectgarbage("collect")) constantly. If your memory usage stops growing with that, the issue is as described, and not a leak (leaked memory, by definition, would not be reachable by the GC).

[actionless]

@sclu1034 if you wanna discuss each of them - i guess better place would be there (https://github.com/awesomeWM/awesome/issues?q=is%3Aissue+is%3Aopen+memory+leak+)