On 5/17/24 4:01 AM, Grisha Levit wrote:
Looks like `read -e -u N' creates (and leaks) a new stream for fd N. If a second `read' tries to fdopen the same fd once more, Android's FDSAN (on and enforcing defualt) causes the process to abort:
I suppose this has value as a warning, but causing an abort seems ... overzealous.
$ bash -c 'read -eu3; read -eu3' 3<&0 fdsan: failed to exchange ownership of file descriptor: fd 3 is owned by FILE* 0x7131a45d18, was expected to be unowned Aborted bash -c 'read -eu3; read -eu3' 3<&0 I guess when Readline is being used for `read' input, a proper thing to do is dup() the fd supplied by -u (thereby defeating the point of the option..) and fclose() the resulting stream when done.
Yes, I suppose that avoids the android crash. It would be nice if there were a way to deallocate the FILE * without touching the underlying file descriptor (kind of the opposite of fdopen) or if there were some equivalent of fileno() that could be used as an lvalue, so you could set the fd in a FILE * to -1 and just call fclose() to deallocate it. The dup2 is what I was trying to avoid, and accepted the small memory leak as a consequence. But stdio has only a limited understanding of non-stdio managed file descriptors.
I think the current behavior is due to a report[1] about -u being silently ignored with -e, though maybe forbidding the combination explicitly would be fine too.
No, that would run counter to user expectations.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
