Could changed enviroment cause all this problems???

[Manne Andersson]

We have built an application using Tuxedo 6.5, Oracle 7.3.4. This was done 1.5 years ago. The problem started when we had to fix a bugg in our code. We fixed the bugg, added a few rows in a Tuxedo services and we noticed that the services (and Tuxedo server) crashed. We searched on and found out that it crashed when it was trying to call a standard library function in one of our *.sl files. We put on the flag -vshlibunsats flag and noticed that it could not resolve the standard c functions so we added -lc when linking in our makefile. That did not help. We back the bugg fix to our original code that compiled and worked correctly 1.5 years ago and compiled again. It did not help.

So we are compiling the exact same code with the exact same makefile with the exact same configuration files (Tuxedo) that worked 1.5 years ago. What can be wrong? This indicates to me that something has been changed in our environment. We have installed a lot of other programs like Tuxedo 7.1, WLS 6.0, Oracle 8.1.7, aCC, Tibco and even some HP pathes.

We use cc to compile 32 bit code on an HP-UX stardust B.11.00 A 9000/800.

(1) Whether we had the unsatisfied symbol problem before I do not know, we obviously have them now by the way. Question, could unsatisfied symbols be "magically" fixed during runtime with environment variables like SHLIB_PATH? Our SHLIB_PATH looks like this: SHLIB_PATH=/opt/tuxedo65/lib:/opt/lastkaj/Dev_V8.1.2A/Appdir/lib:/usr/lib

(2) We tried to comment out the calls to the shared library (GeneralUtil.sl) that in turn calls the standard library. We got the following senario (<-- means uses)

Do not work:

TuxServer <-- adress.sl <-- GeneralUtil.sl <-- libc.sl

Works:

TuxServer <-- adress.sl <-- libc.sl

Why can we call standard c functions directly from our adress.sl file and not indirectly via our GeneralUtil.sl?

(3) It seems like it does not matter if we resolve the unsatisfied symbols or not, the Tuxedo Server crashes anyway at the same position when calling a standard c function.

I need input were to search and look for answers. I have added parts of the build log.

Regards,
Manne

[Hartmut Lang]

Only some hints:
Check your /usr/lib directory.
On my HPUX11i machine it looks like (for libc):
libc.0 -> ./libc.1
libc.1
libc.2
libc.a
libc.sl -> /usr/lib/libc.2

Which means to me that there are different version of this shared-library. If you create a new binary(executable), you will link to the latest version. But maybe your original application was using an older version. That may cause your problem.
Use chatr with your original executable to check which shared-lib version is is using.

Hardy

[Olav Baadsvik · Accepted solution]

Adding this info as it may of interes to
others. The problem here was
found to be a programming error.
In his code he had the following:const char *formatBufferIN = "%z2%s13%s22%d5%s1%s4%s4%s2";

formatBufferIN was then passed to a function
that sent it through the function tolower,
meaning that he trid to change a constant.

The reason your old compiled version of this code does not fail is that the compiler now is
changed to by default store const char in read-only memory.
The following from the release-notes explains this:

+ESconstlit and +ESnolit compiler options

The +ESconstlit and +ESnolit compiler options have been added to HP C. These
options, grouped with +ESlit, control HP C's storage mechanism for strings
in read-only memory.

* +ESconstlit introduces a new default behavior, in which the HP C
compiler stores constant-qualified (const) objects and literals in
read-only memory.

* +ESnolit compiler option disables the default behavior, and causes the
HP C compiler to no longer store literals in read-only memory. This
restores the compiler's traditional behavior prior to this release.

* Use of the +ESlit option places all string literals in read-only memory

Storing const-qualified string literals in read-only memory can cause a
program which violates the semantics of const to abnormally terminate with a
bus error and core dump. This is because literals, which have been placed in
read-only memory may not be modified at runtime. Specifying +ESnolit will
allow you to specify that literals not be placed in read-only memory.

The following little tesetprogram demonstrates this:

#include

int main(int argc, char* argv[])
{
const char *xxx = "ABCDEF";
char *yyy = "abcdef";
printf("Kompilert uten +ESnolit - core-dump..\n ");
strcpy ( xxx,yyy );
printf(" resultat: %s \n ", xxx );
return 1;
}

Compile this program like this:

cc -o bug.exe bug.c
and you will have a bug.exe that coredumps.

Compile it like this:

cc -o bug.exe +ESnolit bug.c

and it will not core-dump

Conclusion:
Compile your code with the option +ESnolit


Olav Baadsvik