NULL problem in HP server

[KarthiKhivi]

Hi All
I am facing a problem in a C code which is working perfectly in AIX platform, but in HP it fails. In HP server, when i call a function in c using sample(NULL) it fails but when i call the same using sample(""), it works. This behaviour is looking strange in HP boxes. Can it be fixed say by caling that function using sample(NULL)? Can anybody suggest a solution?
The version of HP is B.11.11 U 9000/800.
Thx for your help inadvance.

[KarthiKhivi]

Adding to that, here is a sample code which works on AIX platform but not on HP.

#include
int main()
{
char **variable=NULL;
printf("Starting\n");
fflush(stdout);
while(*variable)
{
printf("Inside while\n");
fflush(stdout);
break;
}
printf("Ending\n");
fflush(stdout);
}

The output is:

Starting
Memory fault(coredump)


Can anybody make it work on a HP machine?
Thanks.

[Venkatesh BL]

It works on my 11.31. What is the compiler version and options you are using?

[Matti_Kurkela]

NULL is a pointer pointing to a "nowhere" memory location. The actual content is implementation-dependent: it may be e.g. 0x0000000000000, or it might be some other value that is known to be invalid. The invalidness of the value might even be enforced at the CPU hardware level: trying to access anything pointed to by a NULL pointer may (and *should*) cause an immediate segmentation fault.

An empty string ("") is a pointer to a valid memory location which only contains the string terminator character, '\0'.

These are two different things.

As we don't have access to the source code of your function, I cannot see what is wrong. But I guess that the function does not properly check its input for NULLness: it might make *some* checks that are adequate for AIX, but not good for portable C code.

From a document "Recommended C Style and Coding Standards":
http://www.psgd.org/paul/docs/cstyle/cstyle.htm

Chapter 16, "Portability":

[...]
# On some machines, the null character pointer ((char *)0) is treated the same way as a pointer to a null string. Do not depend on this.
[...]

Obviously, the AIX programmer that wrote the code has not read this document.

MK

[Don Morris_1]

So you're doing --

char **variable = NULL;

while (*variable) {

So really, you've written while (*NULL). NULL should not be dereferenced. If you set variable to "", that still isn't exactly right (since "" is a constant array of char, not a char **... this is just the empty string. You could set *variable to "", but first you'd need to allocate memory for a char * to do that).

I would suspect the problem in the real code may be similar -- if the sample() function expects a valid string -- calling with NULL means the function will attempt to check the string length of an invalid pointer. Boom. Calling with "" on the other hand _is_ a valid [empty] string, hence why it works.

The obvious fix if you truly want to call sample() at times with no string is to have a check at the start of sample() for if (input == NULL ) { return; // Or do whatever is reasonable here, but don't deref! } .

[KarthiKhivi]

Hi All

Thanks for your quick and valuable response. i ve already given a sample code which works on a AIX machine but not in HP. That is a very simple version of our huge application. The actual application has 100k such codes. So we are in a state to find out a solution other than code change.

[KarthiKhivi]

Hi Venkatesh

Thanks for your reply.

Wats the compiler version using? we haven't used any options while compiling. we are using GCC as compiler and its version is "gcc version 4.1.2". Since GCC is a freeware we are using this compiler.
Wats the difference in ur version of server and ours? Can we make it work in our machine with any configuration settings change?

[KarthiKhivi]

Hi Don Morris

Thanks for your inputs

We cant afford to make such code changes in our application since it has around 100K LOC. :(
Need to fix without code changes. Thats the sad thing here.

[KarthiKhivi]

is it possibile to instruct compiler while compiling not to use "0x0000000000000, or it might be some other value that is known to be invalid" and instead use a valid segment area? Any options can be added for the same?

[Don Morris_1]

With gcc? I'm not entirely sure -- Dennis probably will know. On newer releases of HP-UX, there's a chatr option (-Z) that disables the trap for NULL dereferences. I believe on v1, you can pass a flag to the compiler or linker (http://docs.hp.com/en/1694/comp_run.html, http://docs.hp.com/en/B2355-90689/ld.1.html), but that's the HP compilers -- not gcc. If gcc ends up invoking ld, then you just need it to pass "-Z" to ld in the linking stage. I expect it does (since a portable linker seems like an odd choice) -- but I'm not even vaguely up to date on gcc choices/internals.

That said, this is not what I'd call a good idea and you've got some risk here. If all this thing ever does is treat NULL like a string, attempt to look for the '\0' terminator... then you're probably okay [since I believe you get to read zeros from the Zero page when NULL deref is disabled, and 0 looks like '\0' if my memory serves]. Hence a string operation on NULL in this model will see an "empty" string right off and you'll survive. If your code tries to do anything later like store something to that string buffer, you're still hosed. At least since it runs on AIX (and has for a while), the odds are it doesn't do that.

So "-Z" will probably get you going -- but I'd still fix that source in the future to have more clean portability.

[Dennis Handly · Accepted solution]

>Can anybody make it work on a HP machine?

Why? This code is illegal. Unfortunately it should work by the linker default, -Z.

>works on a AIX machine but not in HP.

What linker options are you using?

>is it possible to instruct compiler while compiling not to use "0"?

No.

>instead use a valid segment area?

That's the default for read. Trying to modify will always abort.

>Don: So "-Z" will probably get you going -- but I'd still fix that source in the future to have more clean portability.

Right. But since -Z is the default, you'll need to look for -z.

[KarthiKhivi]

Thanks Dennis

We made that sample code work by using -Z option in GCC. But even this approcah fails in our project, sice we are making a shared library and making use of that. Its a JNI project with Java and C. :(

[Dennis Handly]

>We made that sample code work by using -Z option in GCC.

It appears that gcc hates bad programmers and by default passes -z to ld.

>making a shared library and making use of that. It's a JNI project with Java and C

I suppose you could copy java and "chatr -Z java" and then use that?
But I don't know what will be broken in java, if that trap is removed?

[Steven Schweda]

> [...] But even this approcah fails in our
> project, [...]

There is much to be said for fixing your
really very bad code.

[KarthiKhivi]

Hi Dennis

"I suppose you could copy java and "chatr -Z java" and then use that?"

Could you explain wats the purpose of "chatr -Z java" and for wat it is used? wer to use this? I'm new to this command.

Thanks.

[Dennis Handly]

>Could you explain what's the purpose of "chatr -Z java"

It does the same as linking java with -Z.
Copy the executable, make it writable, use chatr, make it read only.
Then test. It may not work unless the modified executable is in the original directory. If so, you should give it a different name. Then see if it works.

[KarthiKhivi]

Hello All

Thanks for your valid inputs.

With the help of -Z option in GCC command, 20% of our application which is not in JNI worked. But the remaining 80% of application which is in JNI fails even with -Z option in GCC command.

Is there any command which can be used with GCC or with Javac or somewhere that makes my JNI portion also wrking?

Expecting your inputs.

[Andrew C Fieldsend]

Assuming you're passing these dereferenced null values through JNI, then Java is trying to work with either a null or semi-random pointer value.

(If I remember correctly, the -Z flag allows dereferencing of null pointers by mapping a small block of zero-intialised memory starting at address 0, but I'm sure Dennis can correct me on that.)

Java was designed to have no way to ignore reference errors. When you say that the 20% in JNI fails, do you mean it crashes, or do you get Java errors?

[KarthiKhivi]

Non JNI means creating exe files (which is workign with -Z option in GCC command). Now the issue is with the JNI portion.
We are creating a shared library which will be used by JVM. -Z doesnt seem to work with shared libraries.. or Java is unable to handle null ptr reference. JVM crashes after receiving a SIGSERV error and a core file and a log file (hs_err_pid28587.log)getting generated.

With all your inputs 20% of Non JNI (exe) worked. Still need your inputs to make the other 80% JNI stuff to work.

is there a way to make java handle the null ptr reference, like how -Z made exe work?

[Andrew C Fieldsend]

Sorry, I wasn't very clear with my earlier post - but you've answered my question. What I actually meant to say was whether you had a Java stack dump from a null pointer exception, or an actual SIGSEGV crash.

The Java stack dump would indicate that Java had successfully interpreted the null pointer from the C code as a Java null reference, while the SIGSEGV indicates that the JVM is failing to dereference the null pointer internally.

You could possibly use Dennis' chatr command on the "java" executable itself, but I'm fairly certain that you would then get Java null pointer exceptions (from the dereferenced C null pointer) at some point. There's no way to turn these off in Java, other than by using a try...catch block around the JNI call to handle the exception.

[Dennis Handly]

>Is there any command which can be used with GCC or with Javac or somewhere that makes my JNI portion also working?

I told you how to attempt to do it by modifying the java executable.

You can also throw away the java executable and write your main in C then invoke the JVM.

>-Z doesn't seem to work with shared libraries.

That's correct, -Z/-z only apply to the whole process, the executable.

>Andrew: the -Z flag allows dereferencing of null pointers by mapping a small block of zero-initialised memory starting at address 0

Yes. Shared for all processes.

>I'm fairly certain that you would then get Java null pointer exceptions (from the dereferenced C null pointer) at some point.

That's impossible. By using -Z you have prevented all signals on read of NULLs. If getting this signal is important to Java, you'll have problems.

[Andrew C Fieldsend]

Dennis, I'm not entirely sure, but I think Java may also do internal software checks for null pointers in the JVM, rather than depending only on signalled zero-page accesses. (Obviously, this will depend on the particular JVM implementation.)

[Dennis Handly]

>Andrew: I think Java may also do internal software checks for null pointers in the JVM

That's possible but using -Z won't change that.
(I'm assuming the null pointers only appear in the JNI code and don't escape to java.)

[Andrew C Fieldsend]

Sorry Dennis, I meant Java null pointers returned from JNI as a result of indirection through a (char **)0 with -Z in force.

[Dennis Handly]

>Andrew: I meant Java null pointers returned from JNI

Yes, that would be bad. KarthiKhivi should change those places.