Summary: (late) Possible compatibility problem Sol 2.6 and 2.7

From: Magnus W (magnus.walldal@cognition.se)
Date: Tue Nov 30 1999 - 12:10:48 CST


Sorry for this rather late summary! I cought the flu :(

Thanks to Casper Dik, David Robillard, Kevin Sheehan, Aki Sasaki and
others who responded!

Well, I did not find a direct solution for the problem, but something
is different in Solaris 7.
I played around with gdb and found that on Solaris 2.6 the FP and SP
registers corresponds
to each other, they apparantly point to some location in the stackframe.
But, when I run a
Solaris 7 app - the FP register is *not* pointing to an address inside
the stack. Strange but true.
Going deeper inside the application I eventually found a small routine
that relied on FP for
calculating the stack base, and thus it gave the wrong result on Sol 7
and not on 2.6.

Regards,
Magnus Walldal
mw@cognition.se
System Engineer
Cognition AB (http://www.cognition.se)
S-431 85 Mölndal
Sweden

The question was:

I've run into a possible compatibility problem between Solaris 2.6 and
Solaris 2.7.

My app which is a document management tool worked just fine until we
decided to upgrade our Sun Ultra Enterprise-250 from 2.6 to 2.7. At
first I
suspected some faulty library, so we did apply publicly available
patches,
this did not help. The application just dies complaining about the
direction
of the stack.

Then I tried increasing available stackspace for the process to 64K but
that did
not help either (and was not required when run on 2.6). The application
in question
seems to be a normal 32-bit program. Doing 'file' on the executeable
gives: ELF 32-bit
MSB executable SPARC Version 1, dynamically linked, stripped

Some output of what happens follow:

The following messages is from our app when it dies (yes, this comes
from the
application, and not from some library. I checked this with 'strings'):

*Log file: /export/home/spider/spider/admin/logs/sulu.err
*STACK_GROWS_DOWN is defd, but stack appears to grow up
*sp = 0xffbef684, GC_stackbottom = 0x0
*stack direction 3

Truss was not much help :(

Output from 'truss' just before process dies (it dies very early in its
execution):
...
open("/usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1", O_RDONLY) = 4
fstat(4, 0xFFBEF354) = 0
mmap(0xFF360000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0)

= 0xFF360000
mmap(0x00000000, 16384, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xFF330000
close(4) = 0
close(3) = 0
munmap(0xFF360000, 8192) = 0
write(2, " S T A C K _ G R O W S _".., 55) = 55
...

I really dont have much more to go on...



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:33 CDT