You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This part of reopen_standard_stream mixes operations at the fd level with operations at the FILE level in a way that doesn't make any sense to me and, as reported (somewhat incoherently) at https://stackoverflow.com/questions/70879665/ , can wind up corrupting the C library's internal state associated with stdout. Also, several of the error handling paths are incorrect and would cause either crashes or file descriptor leaks.
To the extent I understand what this is trying to do, it looks like a corrected version would be
That is, don't try to close the original FILE object at all, just make a second FILE pointing to a duplicate of the original file descriptor, which the library can use internally as it sees fit.
It's possible that my suggestion doesn't accomplish what this code is supposed to do; if you could explain the actual goal I can maybe give better advice.
The text was updated successfully, but these errors were encountered:
The core problem was ensure what kind of buffering glibc will use - and since lvm2 works across numerous version of glibc - various versions seemed to have different problems with our major requirement to use already preallocated buffer (so glibc does not resize/reallocate it's internal stream buffers later while i.e. buffering log output while we do not want any allocation/mmap to happen.
So while the code might look weird we are not aware of any crashes/memory leak with current solution - if there is any - please report as bug with reproducer.
As we no longer support any library usage from lvm (user should stay with call of lvm command - eventually they may try D-Bus - although this API has its limits) - I'm not quite sure what is 2nd. comment about ??
This part of
reopen_standard_stream
mixes operations at the fd level with operations at the FILE level in a way that doesn't make any sense to me and, as reported (somewhat incoherently) at https://stackoverflow.com/questions/70879665/ , can wind up corrupting the C library's internal state associated withstdout
. Also, several of the error handling paths are incorrect and would cause either crashes or file descriptor leaks.To the extent I understand what this is trying to do, it looks like a corrected version would be
That is, don't try to close the original FILE object at all, just make a second FILE pointing to a duplicate of the original file descriptor, which the library can use internally as it sees fit.
It's possible that my suggestion doesn't accomplish what this code is supposed to do; if you could explain the actual goal I can maybe give better advice.
The text was updated successfully, but these errors were encountered: