64-bit c++ application crashing on solaris

Hi,
we are trying to migrate an existing C++ application on solaris
compiled in 32-bit env to 64-bit env.
We have successfully compiled the application in 64-bit mode. We are
facing problems while running the compiled application.
The application seems to be crashing intermittently for no specific
reason.
We think this could probably be due to sufficient memory not available
to the 64-bit application.
we investigated various tunable parameters in solaris for the same
purpose.
A brief description of them is listed below --


lwp_default_stksize

Specifies the default value of the stack size to be used when a kernel
thread is created, and when the calling routine does not provide an
explicit size to be used.

Data Type
Integer

Range
Minimum is the default values:
3 x PAGESIZE on SPARC systems (3 * 8192 = 24576)
Maximum is 32 times the default value.

Units
Bytes in multiples of the value returned by the getpagesize
parameter. For more information, see getpagesize(3C).

Dynamic?
Yes. Affects threads created after the variable is changed.

Validation
Must be greater than or equal to 8192 and less than or equal to
262,144 (256 x 1024). Also must be a multiple of the system page size.
If these conditions are not met, the following message is displayed:
Illegal stack size, Using N
The value of N is the default value of lwp_default_stksize.

When to Change
When the system panics because it has run out of stack space. The
best solution for this problem is to determine why the system is
running out of space and then make a correction.
Increasing the default stack size means that almost every kernel
thread will have a larger stack, resulting in increased kernel memory
consumption for no good reason. Generally, that space will be unused.
The increased consumption means other resources that are competing for
the same pool of memory will have the amount of space available to
them reduced, possibly decreasing the system's ability to perform
work. Among the side effects is a reduction in the number of threads
that the kernel can create. This solution should be treated as no more
than an interim workaround until the root cause is remedied.

segkpsize
Specify the amount of kernel pageable memory available. This
memory is used primarily for kernel thread stacks. Increasing this
number allows either larger stacks for the same number of threads or
more threads. This parameter can only be set on systems running 64-bit
kernels. Systems running 64-bit kernels use a default stack size of 24
Kbytes.

Data Type
Unsigned long

Default
64-bit kernels, 2 Gbytes
32-bit kernels, 512 Mbytes

Range
64-bit kernels, 512 Mbytes - 24 Gbytes
32-bit kernels, 512 Mbytes

Units
Mbytes

Dynamic?
No

Validation
Value is compared to minimum and maximum sizes (512 Mbytes and 24
Gbytes for 64-bit systems) and if smaller than the minimum or larger
than the maximum, it is reset to 2 Gbytes and a message to that effect
is displayed.
The actual size used in creation of the cache is the lesser of the
value specified in segkpsize after the constraints checking and 50% of
physical memory.
When to Change
This is one of the steps necessary to support large numbers of
processes on a system. The default size of 2 Gbytes, assuming at least
1 Gbyte of physical memory is present, allows creation of 24-Kbyte
stacks for more than 87,000 kernel threads. The size of a stack in a
64-bit kernel is the same whether the process is a 32-bit process or a
64-bit process. If more than this number is needed, segkpsize can be
increased assuming sufficient physical memory exists.


Does anyone have an idea about these parameters (or any other related
params), and if they could be helpful in resolving the issue at hand ?
Or is there any other area, we should look at which could help in this
case ?
.

Quantcast