We are using filebuf.open call to open a file in readonly mode in a multi-threaded application. The result of the open call is checked with is_open. The truss log shows that the file was opened successfully giving the file handle. However, the application log shows that the open call failed and that fail() was true with rdstate=4. This behaviour is seen only after a few minutes of application running (during which time it successfully opens the same file).
Hi. Certaintly, we cannot hope to debug further the issue without a proper, self-contained, piece of code useful to reproduce the problem: this is a strict requirement for any PR, in particular for very hard to reproduce issues related to MT. That said, I'm afraid you are assuming a level of MT safety that we don't (wo don't *want*, I would say, but this is very large topic and the actual guarantees are also highly dependent on the underlying libc, which we don't control, unfortunately) provide: for example, if running your application single-threaded or protecting the filebuf operations with a mutex avoids the problem, then very likely we would not consider the behavior a bug.
sample code: fn(const char* fname) { ifstream fstr; if (!fname) return; fstr.clear(); fstr.open(fname, ios::in | ios::nocreate); if (!(fstr.is_open())) { cout << "rdstate():" << fstr.rdstate(); cout << "bad():" << fstr.bad(); cout << "fail():" << fstr.fail(); return; } //Read the file contents } As you can see, the fstr is a stack variable that is used to access the file. The flags were cleared before the open call. When it failed rdstate was set to 4. This function call successfully opened the file multiple times before the failure.
(In reply to comment #2) > sample code: Sorry, but this is not useful. We need a *self-contained* source file, which we can compile and run as-is, using your very same build options. We need to exactly reproduce the problem in all its details before taking any further action.
Feedback not forthcoming.