fopen does not return

Question

I used 'fopen' in a C program to open a file in readonly mode (r). But in my case I observed that fopen call does not return. It does not return NULL or valid pointer - execution gets blocked at fopen call. The patch of file is absolutely correct (I have already verified that) and there is no permission related issues. Can anybody please tell what could be the reason for this kind if behavior. Any kind of help is really appreciable. Is there anything related to gcc or glibc?

EDIT

Here is the sample code

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__);

When I run this code, I only get the first print (before calling fopen) and after that program just halts. So fopen does not complete it's operation. The file is a simple configuration file with '.conf' extension and this file can be opened by all other means like vi, cat etc. There should not be any NFS related issue. Filesystem is ext3.

Thanks in advance, Souvik

Post the code. We can't tell without that. Include the parameters (with values) you're passing to fopen. — The Archetypal Paul
Can you open that file using some other means like cat? One more possible reason is that the file is on NFS. — Sergei Tachenov
@Time Machine: Erm... NULL is an alias for a null pointer. No, the two are not different. — DevSolar
Replace printf() with fprintf(stderr,) followed by fflush(stderr), as there may be buffering issues. Just to make sure that it really hangs on that line. It is also worth printing argv[1] before fopen(). And lastly, did you try to run the whole thing in a debugger? — Sergei Tachenov

nos nos · Accepted Answer · 2010-12-20T21:58:32

Here's a few reasons:

You've corrupted memory somewhere, and all bets are off as to what's happening (run your program through valgrind)
You're calling this code inside a signal handler, fopen() is not signal async safe, so really anything could happen (a deadlock due to the FILE* internal mutex is common though)
The file is a fifo , in which cases opening the file will block until someone opens the file at the other end(read/writing)
The file is on a stale NFS mount.
The file is a character/block special file with semantics that open blocks until something interesting happens,

fopen does not return

4 Answers