64-bits executables not working

[NeerajBhatia_1]

I am porting some code from Tru64 Unix to HP-UX. This code works fine, when 32-bits executables are created, but crashes when 64-bits executables are used.

My first question is related to stacksize. Is it true that there are two system-wide parameters for stacksize, one for 32 and another one for 64-bits.

When I use ulimit, what does it display?

Any help?

[H.Merijn Brand (procura]

use kmtune to see the kernel parameters for those. The names are obvious

[NeerajBhatia_1]

Thanks for your quick tip.

I was worried about the stack on 64-bits, since this application corrupts a string buffer while calling an Oracle (8.1-7) call.

Let me explain the executable environment. It is a multi-threaded server application, calling Oracle db in the backend. As I said earlier, the same code works with 32-bit executables, but fails to work with 64-bits.

I was looking into the stacksize (for a thread), since one of our experts asked me to use "glance" to look for the memory (using s:pid, followed by M). It seems like that 64-bits executable threads are using 32K of stacksize.

How could I find out about the stack allocated for a specific thread?

Neeraj

[A. Clay Stephenson]

ulimit -a displays the 32-bit version. maxssiz, maxtsiz, and maxdsiz all have 32-bit and 64bit versions. e.g. maxssiz_64bit.

[Don Morris_1]

The 32k per thread is the UAREA (not configurable). The configurable stack is for the process as a whole and defaults to 8Mb for both 32bit and 64bit applications, except for 11i v1.6 where the default for 64-bit was raised to 256Mb. The tunables in question are maxssiz, maxssiz_64bit. If you are on an IPF box and the application is compiled for PA-RISC you also need to look at pa_maxssiz and pa_maxssiz_64bit.

If you're hitting the process stack limit you should get a SIGSEGV with a message that it is caused by stack growth failure. If you could describe how the application fails it would help.

The first thing that leaps to my mind is that perhaps you have a function defining an array of longs (or such) so that the array size doubles for 64-bit compilation and exceeds the process stack. Just the first thing I'd check without more information.

[NeerajBhatia_1]

Hi Don,

I don't understand your comment. We use "pthread_attr_setstacksize" function to set the thread stacksize to 96K at thread-creation time.

Is it not going to work?

What do you mean by 32K UAREA?

We need a larger stack for these threads, since they call many functions with lots of local variables. No, we don't have an array of longs. The corruption seems to occur in a char array.

Regards,

Neeraj

[Don Morris_1]

The 32k UAREAs are where the stack for kernel operations as well as other useful information for context switch is stored.. which is what it sounded like you were seeing in Glance.

I'll say up front that I'm not a pthreads guru by any means -- it sounded like a core kernel VM question, hence my interest. pthreads manage the memory for their stacks themselves, so I don't have easy answers. From my cursory inspection however:

1) Does pthread_attr_getstacksize() on the 64-bit application return 96k as expected? Always nice to check to make sure something didn't get garbled on the system call. [Side note - I don't see why pthread_attr_setstacksize() wouldn't work as long as the linker is getting the 64-bit library... which I have to assume it is.. you'd get EINVAL if the operation failed entirely.

2) The pthreads allocation goes through mmap and sets up variable, private memory ranges for the stacks. Just to check - is glance showing 32k for the RSS or VSS for the mmap regions corresponding to the pthread stacks?
(I don't see stack sizes listed in glance -- I can get to it in gpm, though...). If the RSS is 32k but the VSS is 96k things are normal - you're just only touching 8 pages on the stack.

Looking at the memory ranges and figuring out which goes with which thread would be tough to do from glance. I can't think of a non-kernel intrusive way to do it... but I think that has more to do with the fact that the way I work tends to be kernel intrusive by definition, sorry. You should be able to verify the stack size issue by running a single thread in a process being monitored by glance (preferably having the thread initialization wait until you're ready, I would think) and just look for a private mmap allocation.

Sorry I can't be of more help.

[rick jones]

it is my understanding that even in 64-bits, the addresses one gets on Tru64 remain below 4GB until an application actually allocates > 4GB of space. This will "hide" problems such as still casting pointers to ints instead of longs.

on the other hand, 64 bit applications under HP-UX will get addresses with values above 4GB even if they do not allocate > 4GB of memory. this will "expose" problems just as still casting pointers to ints instead of longs.

not sure if it is related, but seemed worth mentioning.

on the DSPP (via devresource.hp.com) there may still be pointers to the scanning tools for 32 to 64-bit migration. you may want to get those and run your sources through them.