Memory access violation when running in cron

[jdorminey]

Hello,

We have a program that is throwing a memory access violation, when being ran from a script on a Linux server. When we run the program in debug on the same server, it runs through, no problem. The same exact program and script run on AIX with no issues.

Could anyone suggest a solution, or the best way to troubleshoot this issue?

Thanks...

[shjerpe]

On Linux, in the acu\bin directory run acushare -clean 

then you'll need to start acushare

does the script include the runtime -b option ... runcbl -b -c myconfig myprog

Does your program make any type of log showing which portions of your program succeeded, in order to determine where the mav may be occurring.

Are the environment variables, directory and file permissions, especially PATH the same for cron as they are for the user who can run the program successfully.

[jdorminey]

Yes, we use the -b option in the command line. 

Looking at the address at which the error file indicates the program failed there is a string statement. We have moved the code around, and the failure moves as well, not always to the same piece of code, but the pattern seems to be that it always failing on a "String" statement. Again, not always the same string statement, but a string statement. 

We have 15-20 other programs developed and ran in the same manner that do not fail. It is just this one.

Any suggestions would be appreciated.

Thanks, 

James 

[rzack]

If it is possible to relink the runtime (since you're running Linux, this is likely, though you may need to install a C development system), then do so as follows:

In lib/Makefile, look for a line

LDFLAGS = -s $(EXTRA_LDFLAG)

Get rid of the -s. Then execute 'make' to relink the runtime. Move the new runtime (or libruncbl.so) to the bin directory so that you are using it.

In cron, include the -z option when executing the runtime. This will cause the runtime to actually create a core file, rather than a Memory Access Violation.

That core file can be used with the runtime and gdb to determine the location of the crash:

gdb runcbl core

From the gdb prompt, type 'where' to get a stack trace. 

You may need to raise a support incident in order to get this fixed. It will also help to know what version you are using.