process-util: don't use overly large buffer to store process command line

[msekletar]

Allocate new string as a return value and free our "scratch pad"
buffer that is potentially much larger than needed (up to
_SC_ARG_MAX).

Fixes #11502

[keszybz]

It'd be possible to be a bit smarter when the strdup is done. E.g. in the kernel thread case, we allocate a string of precisely the right length, so we could avoid the copying without any loss.

I don't think this is a the whole solution. It seems the "leak" is growing and growing, so just making smaller allocations cannot be the whole answer, but this looks like a step in the right direction. So let's merge this, as it should make things much nicer, and look for further improvements later.

[msekletar]

I don't think this is a the whole solution. It seems the "leak" is growing and growing, so just making smaller allocations cannot be the whole answer, but this looks like a step in the right direction. So let's merge this, as it should make things much nicer, and look for further improvements later.

Maybe we should track how big is each ClientContext entry and have limits on how much memory overall can cache consume.

[keszybz]

Maybe we should track how big is each ClientContext entry and have limits on how much memory overall can cache consume.

I'm working on a patch right now.

[msekletar]

@keszybz I've updated my branch. PTAL.

[msekletar]

Ubuntu CI failures are most likely unrelated and seem to be due to packaging issues,

E: There were unauthenticated packages and -y was used without --allow-unauthenticated
autopkgtest: WARNING: Test dependencies are unsatisfiable - calling apt install on test deps directly for further data about failing dependencies in test logs
boot-smoke           FAIL badpkg

[poettering]

The allocation of the sysconf size is still in there. The upper loop should be reworked to do GREEDY_REALLOC() really, so that the buffer increases exponentially in size as needed.

[keszybz]

GREEDY_REALLOC()

I thought about this, but there's an argument for doing this as in the current patch: those strings will be kept in a cache, potentially for a long time, so it is quite worthwhile to minimize the allocation. And if we are going to do the strdup at the end anyway, and the maximum size is fixed anyway and not that large, then it's OK to not use greedy_realloc.

[poettering]

GREEDY_REALLOC()

I thought about this, but there's an argument for doing this as in the current patch: those strings will be kept in a cache, potentially for a long time, so it is quite worthwhile to minimize the allocation. And if we are going to do the strdup at the end anyway, and the maximum size is fixed anyway and not that large, then it's OK to not use greedy_realloc.

it appears to me the right approach is to use greedy_realloc() initially, and then use realloc() at the end to give up the space not actually needed. realloc() is pretty ok for giving up unneeded memory, much better i think than copying yourself