fopen no devuelve

Question

Utilicé 'fopen' en un programa C para abrir un archivo en modo de solo lectura (r). Pero en mi caso observé que la llamada fopen no regresa. No devuelve NULL o un puntero válido: la ejecución se bloquea en la llamada fopen. El parche del archivo es absolutamente correcto (ya lo he verificado) y no hay problemas relacionados con los permisos. ¿Alguien puede decir cuál podría ser el motivo de este tipo de comportamiento? Cualquier tipo de ayuda es realmente apreciable. ¿Hay algo relacionado con gcc o glibc?

EDITAR

Aquí es el código de ejemplo

printf("%s %d\n",__FUNCTION__,__LINE__); 
if ((fp = fopen(argv[1], "r")) == NULL) { 
    printf("%s %d\n",__FUNCTION__,__LINE__); 
    return; 
} 
printf("%s %d\n",__FUNCTION__,__LINE__); 

Cuando ejecuto el código, solo me dan la primera impresión (antes de llamar a fopen) y después de que el programa simplemente se detiene. Entonces fopen no completa su operación. El archivo es un archivo de configuración simple con la extensión '.conf' y este archivo se puede abrir por cualquier otro medio como vi, cat, etc. No debería haber ningún problema relacionado con NFS. El sistema de archivos es ext3.

Gracias de antemano, Souvik

Answer 1

Entonces, ¿qué? fopen puede bloquear hasta que se haya abierto el archivo o hasta que se haya determinado que se ha denegado el acceso. Si tiene un dispositivo de almacenamiento lento, es absolutamente correcto esperar hasta que esté disponible. Pero eso es un problema del sistema operativo, no de C.

Answer 2

Veo que no cierra el archivo si lo abre con éxito.

¿Es posible que lo haya ejecutado antes y lo haya matado, y ahora tiene un proceso que tiene el archivo abierto y bloqueado?

Si es así, quizás fopen esté esperando a que se libere la cerradura.

Answer 3

¿Es posible que haya redefinido un símbolo en el espacio de nombres reservado: algo que comience con dos guiones bajos, un guión bajo y una letra mayúscula, o cualquiera de las funciones estándar de la biblioteca C? Si es así, eso da como resultado un comportamiento indefinido, y es posible que fopen termine llamando parte de tu código en lugar del código correcto en la biblioteca estándar.

Esta pregunta tiene un gran olor a "información faltante". Dudo seriamente que el fragmento de código en la pregunta tenga el comportamiento que OP describió cuando aparece solo en main, y me pregunto si OP no ha hecho algunas cosas falsas sobre las que no nos está hablando ...

Answer 4

Aquí hay algunos razones:

• se han corrompido la memoria en alguna parte, y todas las apuestas están apagadas en cuanto a lo que está pasando (ejecutar su programa a través de valgrind)
• Estás llamando este código dentro de un manejador de señales, fopen() no es señal asíncrona segura, por lo que realmente podría pasar cualquier cosa (sin embargo, es común un punto muerto debido a la exclusión mutua interna FILE *)
• El archivo es fifo, en el que los casos que abren el archivo se bloquearán hasta que alguien abra el archivo en el otro extremo (lectura/escritura)
• El archivo está en un montaje NFS obsoleto.
• El archivo es un archivo especial de caracteres/bloque con la semántica que se abren los bloques hasta que suceda algo interesante,