Programming

Bronchitis is no fun. Get well soon.

Thank you, now we finally know what you want.

Flushing shouldn't matter, anything still in the buffers will be printed before the program exits -- unless your program crashes or is killed by a signal. In that case buffers won't be flushed.

It's probably a better idea to print debug messages to stderr or cerr in general. They never buffer, and won't get mixed in with any data you were expecting on stdout/cout.

If you're using cin/cout/cerr, you should stick to cin/cout/cerr and not use stdin/stdout/stderr. Or vice versa. They compete for the same resources and could conceivably cause each other problems.

If your program isn't crashing and you're not mixing stdio+iostreams and you're still not getting output, something must be closing or redirecting these streams or file descriptors. Try putting this into your program somewhere:

Code:

system("ls -l /proc/self/fd > /path/to/files.txt");

which should print a list of what files and terminals and sockets your application has open into /path/to/files.txt

Thank you so much for your help so far. I just took some medicine and I need to lie down for a while, so I don't fall off my d**n chair. I will add the system ls line and post the output in a little while.

LMHmedchem

---------- Post updated at 07:18 PM ---------- Previous update was at 03:30 PM ----------

I added the system shell line,

system("ls -l /proc/self/fd > /path/to/files.txt");

This is the output,

Code:

total 0
lrwx------ 1 lmh lmh 64 Mar 29 19:03 0 -> /dev/pts/1
l-wx------ 1 lmh lmh 64 Mar 29 19:03 1 -> /home/lmh/openstuff.txt
lrwx------ 1 lmh lmh 64 Mar 29 19:03 2 -> /dev/pts/1
lr-x------ 1 lmh lmh 64 Mar 29 19:03 3 -> /proc/22505/fd

The program arch looks like,

Code:

cpp parent process
   > fork() cpp child process
      > call to Fortran subroutine from child
         > calls to cpp fuctions from Fortran sub

The parent and child pass data through shared memory. I believe that there are pipes as well, but I don't remember.

After adding some additional print statements, I find that I am able to print from the partent process code using std::cout. I am also able to print from the child process code. I am not able to print from the Fortran sub src, or from any of the cpp functions called by the Fortran sub. All of that code is identical for both the windows and linux versions.

I don't know if this helps or not.

Blast, that didn't do what I wanted! It redirected stdout into openstuff to save the list, so we can't see what it had before!

It should still work if we make it ls the parent instead.

Try this:

Code:

// for getpid
#include <unistd.h>

...

// Anywhere in your code
{
        char buf[128];
        sprintf(buf, "ls /proc/%d/fd > /home/lmh/openstuff.txt", (int)getpid());
        system(buf);
}

I was able to get in touch with the coder who wrote this part of the app, and he thinks that possible cout and cerr are re-directed to dev/null somewhere. This was written at least 10 years ago, so his recollections are a bit hazy. Apparently the child process runs more or less like a Daemon and things like standard streams are poorly defined.

He suggested adding a verbosity flag, and if that doesn't work, creating an fstream for debugging with a hard path, instead of using cout. Something like,

Code:

std::ofstream mycout("/tmp/mydebugfile");

None of this explains why it works in windows cygwin, except that the src for the child main function is rather different in windows as compared to linux. I tried a diff to see if I could spot the relevant difference between the src files, but they are a bit too different and the diff is pretty messy.

What should I look for in the src that would be an indication that cout is going to dev/null, or somewhere other than the terminal?

I will run the code you posted above and post back in a bit.

LMHmedchem

---------- Post updated at 01:16 PM ---------- Previous update was at 12:32 PM ----------

I put the code you posted in three places in the code, in case things changed at some point. I put it at the beginning of the parent code, and also in the child main, before and after the fortran function is called.

In all cases, it just outputs numbers, the location outputs 0, 1, and 2. The next location outputs, 0, 1, 2, 3 and 4, and the last location, 0, 1, 2, 3, 4 and 5.

That sounds quite possible. Not really the same program at all, then. I bet that's it. Look for close( or dup( or dup2( or freopen( or STDIN_FILENO or STDOUT_FILENO or STDERR_FILENO. Also look for /dev/null, of course.

Crap. I forgot to do ls -l instead of ls.

Well I found it,

Code:

#ifdef RELEASEVERSION
   freopen( "/dev/null", "w", stdout);
   freopen( "/dev/null", "w", stderr);
#endif

I didn't think that RELEASEVERSION was defined in the make, but commenting this out fixes the issue, so it must be. This is a sensible code addtition, since if there is an error, the child is supposed to report that back to the parent as an error code, not send it to a terminal, which may or may not exist.

I realize that this was a difficult fix without the src available, so I really appreciate all of your effort in helping me to get it sorted out.

I wish I was a good enough programmer to contribute in the same way. I do look for posts that I think I can answer, but most of the ones I find have already been attended to. I am reluctant to give advice that may be incorrect. I give allot of hardware adivce on some other forums, which is something I feel much more competent about, so I hope that I am making an overall contribution the the online world.

Thanks again,

LMHmedchem

---------- Post updated at 02:28 PM ---------- Previous update was at 02:24 PM ----------

Is there a way to mark the thread as solved, or don't they do that here?

A moderator can do that on request, but you can't do it yourself.

Don't think you're that bad a programmer. Helping answer threads here is a good way to learn, too.

Glad you got it fixed!