>But, unless the application is statically linked, the location of errno is 
>not known until application load time; and if it *is* statically linked, 
>then the location of errno is bound at application build time.  It doesn't 
>seem like this could have changed.

Errno is either static storage or it's a function returning a
pointer to thread local storage.

>> The truss output shows that readlink("/opt" ...) returns -1 with error
>> EINVAL.

>> However the test of "if ( errno != EINVAL )" returns true. I guess that
>> the location of errno storage has been changed in the libc, so the
>> application reference errno at a wrong address and get a wrong value.


Either errno is a global variable which is created in the binary
(non-threaded case) and the library will reference the copy in the
binary, not the additional copy in the library.

If the application is compiled as a thread-safe application, the
function "int *__ernno()" is used instead,

>> I tried to debug this issue by dumping debug message to STDERR with
>> fprintf(), got something similar to the write() function call in the
>> truss output posted on our forum:

This points to a form of memory corruption.
 
>> 6871: write(2, "\0\0\0\0\0\0\0\0\0\0\0\0".., 18445580) Err#14 EFAULT
>> 
>> So, I guess, the ABI for fprintf in libc has been changed as well.

No, wrong guess.  We don't do ABI changes.

I strongly suspect that there is some form of memory corruption; this
could be our fault or it could be that you application does something
which is legal but with which it has gotten away with until now.

In your particular case it could be anything other such as the old
gcc compiler and possibly an old GNU linker.

A small self-contained example would be very nice; it may allow us
to tell you where the problem is.

(If it works when we compile it natively under Solaris 8 but not
when cross compiled, then that may tell something too)

We don't change ABIs; and when programs break we do take it seriously.

Casper
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to