Ubuntu16.x(x64)C++中fopen返回异常fp，fileno偶发为0问题排查

环境 #

Ubuntu 16.x (x64) C++

用例代码 #

FILE* fp = 0;
if (ERROR_SUCCESS != stat(pFullPath, &st)) {
    if (0 == (fp = fopen(pFullPath, "w+b")))// 创建文件
        return HRESULT_GET_ERRNO();
    _ASSERT(0 != fileno(fp));
}

问题描述 #

fopen始终成功返回有效指针，但偶尔fileno返回0，且m_pf->_fileno == 0，什么原因会导致该异常的fp？

FILE指针转储信息 #

_flags -72539008 int
_IO_read_ptr 0x0 char *
_IO_read_end 0x0 char *
_IO_read_base 0x0 char *
_IO_write_base 0x0 char *
_IO_write_ptr 0x0 char *
_IO_write_end 0x0 char *
_IO_buf_base 0x0 char *
_IO_buf_end 0x0 char *
_IO_save_base 0x0 char *
_IO_backup_base 0x0 char *
_IO_save_end 0x0 char *
_markers 0x0 _IO_marker *
_chain 0x7fe6368cf540 <_IO_2_1_stderr_> _IO_FILE *
_fileno 0 int
_flags2 0 int
_old_offset 94543438232832 __off_t
_cur_column 0 unsigned short
_vtable_offset 7 '\a' signed char
_shortbuf char [1]
_lock x55fc9c068e50 _IO_lock_t *
_offset -1 __off64_t
__pad1 0x55fc9c070210 void *
__pad2 0x55fc9c068e60 void *
__pad3 0x0 void *
__pad4 0x7fe644d41a93 void *
__pad5 0 size_t
_mode 0 int
_unused2 char [20]

问题解答 #

首先要明确：fileno返回0本身不是bug——Linux系统会为新打开的文件分配当前最小的可用文件描述符。如果你的程序（或者它的父进程）之前关闭了标准输入（文件描述符0），那么后续调用fopen时，系统就会把0分配给新创建的文件，这时候fileno(fp)自然会返回0。

结合你的代码和转储信息，具体分析几个可能的场景：

• 标准输入被意外关闭：检查程序中是否有其他代码路径调用了close(0)，或者是否有依赖的第三方库、子进程关闭了stdin。比如有些后台服务启动时会主动关闭标准输入输出流来脱离终端，这时候fd0就会被释放，后续打开文件就会复用它。
• 文件描述符的复用机制：Linux内核的文件描述符分配策略是「最小可用原则」，这是默认行为。当fd0处于空闲状态时，新的open/fopen调用就会优先使用它，这完全符合系统规范，只是看起来“异常”，因为我们习惯了0对应stdin。
• 转储信息的佐证：从你提供的FILE结构体转储来看，_fileno明确是0，其他字段（比如读写指针全为空）符合刚创建的空文件状态，没有结构体损坏的迹象，说明这个FILE指针本身是有效的，只是分配到了fd0。

验证与解决方法 #

你可以在调用fopen之前，检查fd0的状态来验证猜想：

#include <fcntl.h>
#include <stdio.h>
#include <errno.h>

// 在stat调用后、fopen前添加这段代码
if (fcntl(0, F_GETFD) == -1 && errno == EBADF) {
    printf("标准输入（fd0）已被关闭！\n");
}

如果不想让新文件占用fd0，可以在程序启动时提前绑定stdin到/dev/null，避免后续复用：

// 程序初始化阶段执行
close(0);
open("/dev/null", O_RDONLY);

总结一下：这种情况不是fopen或fileno的问题，而是系统文件描述符分配机制的正常表现，核心原因是标准输入被提前关闭了。

内容的提问来源于stack exchange，提问作者NadavRub