Syslinux - Feb 2016 - [PATCH 2/2] core: Fix stack overflow when reloading config

On 01/26/16 07:36, Celelibi via Syslinux wrote:
> 
> From what I've seen, I think there are memory leaks a bit everywhere.
> And it's practically unavoidable since modules are always forcefully
> unloaded instead of letting them gracefully terminate.
> 
> Then, as I already mentioned somewhere else, I think we would need a
> global resource tracker so that when a module is unloaded (or
> simili-unloaded if it stays in memory anyway as discussed above) its
> allocated resources (memory, opened files etc) can be freed anyway.
> 
> That would, of course, not work for the resources allocated by the
> core module, but that could help tracking the growth of the allocated
> resource and thus help debug them.
> 
We actually *have* a resource tracker; the malloc() implementation is
explicitly designed so it keeps track of the owner module in order to be
able to purge the contents on module exit.  We would still do that, just
as now, the only difference is that we wouldn't purge the readonly
segment(s) of a module nor the backup copy of the read-write segment(s).

	-hpa

2016-02-01 11:14 UTC+01:00, H. Peter Anvin <hpa at
zytor.com>:
> On 01/26/16 07:36, Celelibi via Syslinux wrote:
>>
>> From what I've seen, I think there are memory leaks a bit
everywhere.
>> And it's practically unavoidable since modules are always
forcefully
>> unloaded instead of letting them gracefully terminate.
>>
>> Then, as I already mentioned somewhere else, I think we would need a
>> global resource tracker so that when a module is unloaded (or
>> simili-unloaded if it stays in memory anyway as discussed above) its
>> allocated resources (memory, opened files etc) can be freed anyway.
>>
>> That would, of course, not work for the resources allocated by the
>> core module, but that could help tracking the growth of the allocated
>> resource and thus help debug them.
>>
>
> We actually *have* a resource tracker; the malloc() implementation is
> explicitly designed so it keeps track of the owner module in order to be
> able to purge the contents on module exit.  We would still do that, just
> as now, the only difference is that we wouldn't purge the readonly
> segment(s) of a module nor the backup copy of the read-write segment(s).
That's nice to hear. It then should be easier to implement something
to catch use-after-free bugs. I think I've seen some.

However, is there something similar for file descriptors? I also think
I've seen some file descriptors never closed.


Celelibi

On 02/03/2016 07:16 AM, Celelibi via Syslinux wrote:
> 
> However, is there something similar for file descriptors? I also think
> I've seen some file descriptors never closed.
> 
All file descriptors are part of the files[] array, so it would be
trivial to implement a close_all_files() function:

void close_all_files(void)
{
	int i;
	struct file *file = files;

	for (i = 0; i < MAX_OPEN; i++) {
		if (file->fs)
			_close_file(file);
		file++;
	}
}

	-hpa