You are really asking for the impossible. Hoping that someone will be able to debug your code on the basis of a few hundred lines of debugger output.

Reading the sparse details of what you are doing (which is drowned in that sea of mostly useless debugger output), is this a fair summary of your application?

You have an application (Perl?) that forks a child process (Perl?) that:

• Spawns several ithreads each of which:
  1. Write a file
  2. Forks a C++ application that reads and processes that file and writes (pipes) data
  3. Processes the output from the C++ app and uses DBI to talk to a DB.

Assuming that's correct, a couple of comments.

1. Very few people (maybe 3 or 4 in the last 7+years), have come here describing code that combined both forking and threading in the same application.

   And of those 3 or 4, none have ever come back and described having successfully solved whatever problem they originally came here with.

   That doesn't mean they never did solve it, far too many posts here never get a "i finally solved it this way" summation, but it does tend to indicate that you are moving in what is fairly uncharted waters.

   That said, if the initial fork is done prior to any threads being spawned, and any subsequent re-fork of the parent is waiting until the initial child fork is complete, there's probably no great dangers with that.

   But note, that is just speculation, as I don't use any systems that support a true fork.

2. Using DBI in multiple threads is historically, (and to the best of my knowledge still generally) considered a no-no.

   You describe: "In-order to maintain thread-safe manner( as DBI is not safe) I have made local to thread function whatever DBI object I am creating."

   Again, historically, this is not enough. Although logic implies that using different DBI instances from different threads should be "thread-safe"--and probably is at the Perl level--the real problems with thread-safety often lie in the vendor supplied C-libraries and XS wrappers around them. If they are not thread-safe internally, then there is little you, or the perl authors can do about it at the perl level.

   That does not mean that on your particular platform and DB vendor, that DBI isn't thread-safe, but it does mean that you should attempt to find out whether it is? And should perhaps assume it isn't until you get positive confirmation to the contrary.

None of this is very helpful, but it may give you cause for pause in assuming that what you are doing is inherently flawed or not. You might also try asking on DBI/Oracle news groups for further information.