Core dump when running from crontab

[ph_trooper]

Hi

I have a program that runs ok when executed from the bash but ends up with a core dump when running from the crontab.
The program is constructed in C/C++ and the linux platform is RedHat for Itanium 2.

The program is executed by a script, the same in both situations, with the env set to be exactly equal (I checked this by printing env in each execution).

What else changes when executing the same script from bash and crontab??

The block of core that generates the core dump is apparently well constructed, it is a shared library used is many of my applications, none of which breaks.
My only clue is that somehow the process addressing space is different when running from bash and crontab. Does it make any sense?

[lomcevak]

When something is run in crontab the user's profile isn't first executed as it is when you log in. So I suspect there's something else in your login profile that's missing thus causing the core dump. Maybe add to the script to source your login profile?

[Rubberman]

Have you run a post-mortem in the debugger? If necessary, build your executable with the -g option and don't strip the binaries so you can look at the call stack and variables.

[ph_trooper]

Hi!

When something is run in crontab the user's profile isn't first executed as it is when you log in. So I suspect there's something else in your login profile that's missing thus causing the core dump. Maybe add to the script to source your login profile?

In the script, executed both by crontab and manually on bash, I load the profile:
. $HOMEPATH/.bashrc

Everything in the env is equal!
Is there anything else that differs crontab from bash?

Have you run a post-mortem in the debugger? If necessary, build your executable with the -g option and don't strip the binaries so you can look at the call stack and variables.

The code dump is complicated to explain, but I have the stack trace and the exact line where it crashes.
The C++ binary loads JRockit JVM, therefore the exception in C++ code is caught by the JVM.
Moreover the instruction is a simple initiation of a pointer to NULL, the same instruction that runs several times before.

Can a process when runned from cron have a different address space? Or something like that? Which in the end give me an illegal memory access.



Thanks!

[Rubberman]

Ok. So you are running Java code in the C++ program. My guess is that the PATH and/or other environment variables required for Java are not set right. Most specialized environment variables are set with ~/.bash_profile, not ~/.bashrc so you might want to make sure that you source that before ~/.bashrc.

[ph_trooper]

Ok. So you are running Java code in the C++ program. My guess is that the PATH and/or other environment variables required for Java are not set right. Most specialized environment variables are set with ~/.bash_profile, not ~/.bashrc so you might want to make sure that you source that before ~/.bashrc.

I'll check those scripts, however if env has the same values the environment can be different?

I tried to use strace to capture more information, and until now it made the error stop occurring.
I used the command:
strace -o /fullpath/strace.txt CMD

Any clue why apparently the error stopped?

[Rubberman]

Another thought, and something that has bitten me on the rear a few times in the past with this problem, is the fact that cron is "headless" in that there is no terminal (tty) for input/output. There are some system calls that will cause an application to core dump if there is no valid stdin/stdout/stderr. That's why I suggested running a debuggable version of the application and they looking at the core file in the debugger to get a better idea where/why it was crashing. I suspect that strace is going to provide the command with some file descriptor for stdin/stdout/stderr so it can intercept error messages.

[ph_trooper]

Another thought, and something that has bitten me on the rear a few times in the past with this problem, is the fact that cron is "headless" in that there is no terminal (tty) for input/output. There are some system calls that will cause an application to core dump if there is no valid stdin/stdout/stderr. That's why I suggested running a debuggable version of the application and they looking at the core file in the debugger to get a better idea where/why it was crashing. I suspect that strace is going to provide the command with some file descriptor for stdin/stdout/stderr so it can intercept error messages.

Do you mean that strace overcomes the limitation of having no stdin/stdout/stderr?

In cron, I have register the command like this:

/fullpath/script.sh >> /fullpath/file.log 2>&1

I think that with this, the stderr is redirected to stdout, and both are redirected to file.log. Thus I should have no error related with the missing stdin/stdout/stderr, should I?

[Rubberman]

Do you mean that strace overcomes the limitation of having no stdin/stdout/stderr?

In cron, I have register the command like this:

/fullpath/script.sh >> /fullpath/file.log 2>&1

I think that with this, the stderr is redirected to stdout, and both are redirected to file.log. Thus I should have no error related with the missing stdin/stdout/stderr, should I?

Well, you can try it. That should work I would think, but remember that I am only surmising that the I/O issue is your root cause. Without verification, which this should do, at least for stdout/stderr, we still cannot be sure.

[ph_trooper]

Well, you can try it. That should work I would think, but remember that I am only surmising that the I/O issue is your root cause. Without verification, which this should do, at least for stdout/stderr, we still cannot be sure.

The redirection of the stdout and stderr are like that from the beginning, they did not solved the problem.
I am stunned with the strace command 'solving' the issue!!

Does the strace command alter the environment or anything that might change the outcome of the app execution?! Well, in fact it alters, but do you have any idea of what it might be?