I read various different articles on different forums where folks posted a similar issue but never read any resolution for that.
We are in process of porting our application to RHEL5 (from RHEL3), and am encoutering strange behaviors in constructor on ofstream. A simple command like - "ofstream filename" hangs the process.
It's happening "always" when it's been called inside of a thread (note that i wrote a simple program that creates 10 threads and calls the ofstream constructer but that DID NOT give me any issues, so certainly there is something else that's affecting too). Our application use semaphores and shared memory quite rigourously which is one difference from the sample program i had tried. Could that be the difference?
Any ideas why could that be caused in RHEL5? The application on RHEL4 never had any issues like these.

I tend to think that some issue in pthread_once function could be causing that, but that's a guess, if someone has verified this. This function seem to get called from within the ofstream constructor (as per another thread on other forum i read), which could be the issue.

Any pointer would be extremely helpful. There can be heck of things that can affect, so if there are any specific things that someone needs to help me out with this, mention those please.
If this is a known issue, any patches that needs to get installed.

The likely reason you don't see a (simple) answer posted is that there is no single (simple) answer.

Over the timeframe possibly covered between RHEL 3 and RHEL 5, libstdc++ has undergone a lot of change. It's been moving closer to doing the Right Thing(tm) over time. But you have to remember you could be dealing with as much as a 5-year technology gap covering a critical period in libstdc++'s evolution.

I'm not so sure you're the victim of a compiler or library bug.

One thing you said caught my attention; you said you "use semaphores and shared memory". Those are meant for communications between processes in multiprocessing (IPC), not threads. Do you have an uncommon program that is both multiprocessing and multithreading? If so, you are walking on a very thin line (called "thread safety") that's been shifting over the time period you're talking about ... your answers are almost guaranteed not to be simple or fixable with a single patch.

Misuse of IPC is quite common in programs designed during the linuxthreads era (prior to Linux kernel 2.6). linuxthreads was broken from the start, it's been replaced by NPTL. You need to make sure your code understands the difference. linuxthreads was a decent approximation of true POSIX thread implementation, but there are significant differences between them. linuxthreads aren't threads; they're separate processes made to look like threads. It's likely that your code did come from that era: the Linux kernel didn't implement threads until 2.6.

With linuxthreads, you needed shmem to share volatile data between "threads", and you needed semaphores to serve as mutexes. Today, you don't. Remember that many of IPC functions are of questionable thread safety, depending on whether you picked Sys V or POSIX IPC. Add to that the fact that libstdc++ itself now uses pthreads calls to implement thread safety, and you can see the potential mess you have on your hands. The truly fatal part about this situation is that work on linuxthreads stopped years ago. I'm almost certain you can't even build a linuxthreads-enabled g++ any more. Whether or not the solution to this problem is simple is related to the complexity of your code -- the only thing I know for sure is that you're going to be changing your code.

If your application really doesn't need IPC, get rid of the semaphores and shmem; use mutexes and thread-shared data areas instead. If your app truly does need IPC, you may wish to review your design and make sure that your program takes required steps to observe thread safety, keeping the transition from linuxthreads to NPTL in mind.

Sorry for the bad news.