Stack is presented clean on N4000 but not D390?

[Steve Lewis]

We are having problems running our code on a D390 HP-UX 11.00 patched to March 2001. It was compiled with Dec 2000 patches on N4000 HP-UX 11.00 . We can run the programs fine on the D class through the debugger, but not without it. It appears to be a variable initialisation issue which we have to sort out anyway.
Can somebody confirm that the N class always presents a clean stack frame to work with whereas the D class doesn't? Its ANSI C 11.01. Also is there a quick fix?

[Steve Lewis]

Sorry I forgot to point out that the same binaries work perfectly on the N4000.

[Stefan Farrelly]

Hp have included a new linker (ld) patch in the March 2001 bundle;

PHSS_22478 1.0 ld(1) and linker tools cumulative patch

Whereas the one in the Dec2000 bundle is;

PHSS_19866 1.0 ld(1) and linker tools cumulative patch

I suggest on your N class with the March bundle remove PHSS_22478 (then it should revert back to PHSS_19866 if you had the Dec2000 bundle on previously) then recompile and copy to your D class and see if it works. If not then download and install PHSS_22478 and run on your D-class, then hopefully your programs will run.

[Vincent Fleming]

By definition, all memory in a C program has unknown contents - it may be clean, and it may not be clean.

So, your program working on the N is a fluke. It shouldn't. You need to resolve the problem of referencing the variable on the stack that has not been set - not relying on the computer giving you clean memory.

I feel for you here - this type of problem can be very hard to resolve.

Assuming that you're having a problem with function parameters on the stack... usually caused by passing too few or too many parameters to the function. (usually too few)
A quick and dirty way of finding this is to grep for the function name in all your .c files, and verify that you're passing the correct number of parameters when calling the function.

Also, make sure that you have a function prototype (which is correct), and recompile all the code. This should catch any calls with the incorrect number of parameters.

Now, if you're having a problem with local variables within functions, you should be initializing the variables when they are declared. (I know - that can mean a lot of work for an existing piece of software) For example:

int my_func( int parm1, char *parm2 )
{
int local_var = 0;

:

Good luck!

[A. Clay Stephenson · Accepted solution]

Hi Steve,

I'm afraid that Vincent has given you the correct answer; your code has been working by accident. If your are fortunate, lint may spot the variables that have been used before having been set.
For example;

int i;

i = i + 1; (link will not flag)
++i; (will flag)
printf("%d",i); (will flag)

Another very common source of the problem you describe is the use of an auto declared variable where a static should have been used to return the address of a string or structure.
For example:
char *my_string(int i)
{
char s[80];

(void) sprintf(s,"%d",i);
return(s)
}

This function will also work on some platforms and not on others. In all cases, the code is incorrect because the space that s points to becomes undefined upon function exit. Whether it works or not depends on the state of the stack at that moment in time. To correct the problem the array s should have been declared
static char s[80] so that the data is allocated in the .data segment rather than the stack.

In any event, you should compile your code with the -g option and no optimizer and then use the debugger to analyze a stack trace to pinpoint your problems.

Hope this helps, Clay

[Steve Lewis]

Thanks for all your help guys. I am not one of the programmers myself and I agree with your analysis wholeheartedly. I think its just a case of our programmers refusing to believe its a problem with their software.