Fopen does not return

Question

I used "fopen" in a C program to open a file in readonly (r) mode. But in my case, I noticed that the fopen call does not return. It does not return NULL or a valid pointer - execution is blocked when fopen is called. The file patch is absolutely right (I already confirmed it), and there are no permissions. Someone can tell what could be the cause of this kind if behavior. Any help is really noticeable. Is there anything related to gcc or glibc?

EDIT

Here is a 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 get only the first print (before calling fopen), and after that the program just stops. Thus, fopen does not exit. The file is a simple configuration file with the extension ".conf", and this file can be opened in all other ways, such as vi, cat, etc. There should not be any problems with NFS. The file system is ext3.

Thanks in advance, Souvik

Answer 1

Here are a few reasons:

• You have a bad memory somewhere, and all bets are turned off regarding what is happening (run your program through valgrind).
• You call this code inside a signal handler, fopen () is not safe for an asynchronous signal, so something can really happen (a deadlock due to the internal FILE * mutex is common)
• A fifo file in which file open cases are blocked until someone opens the file at the other end (read / write)
• The file is on an obsolete NFS mount.
• A file is a special file with a symbol / block with semantics that opens blocks until something interesting happens,

Answer 2

So what? fopen is allowed to block until the file is opened, or until it is determined that access is denied. If you have a slow storage device, it’s absolutely right to wait until it becomes available. But this is an operating system problem, not C.

Answer 3

I notice that you do not close the file if you successfully opened it.

Is it possible that you started it earlier and killed it, and now you have a process in which the file is open and locked?

If so, then perhaps fopen expects the lock to be released.

Answer 4

Is it possible that you redefined a character in the reserved namespace: something started with two underscores, underscores, and capital letters, or any of the standard C library functions? If so, this leads to undefined behavior, and it is possible that fopen somehow ends up calling part of your code instead of the correct code in the standard library.

This question has a great smell of "missing information." I seriously doubt that the code snippet in the question has the behavior described by the OP when it appears on its own in main , and I wonder if the OP didn’t make some kind of fictitious material that it doesn’t tell us about ...