cancel
Showing results for 
Search instead for 
Did you mean: 

possible stack overflow

 
mrmo07
Regular Advisor

possible stack overflow

Hi experts !!

getting below in dmesg output: hpux 11iv3:

 

Pid 13743 was killed due to failure in writing the signal context - possible stack overflow.

 

# swapinfo -tam
             Mb      Mb      Mb   PCT  START/      Mb
TYPE      AVAIL    USED    FREE  USED   LIMIT RESERVE  PRI  NAME
dev       16384       4   16380    0%       0       -    1  /dev/vg00/lvol2
reserve       -   15489  -15489
memory    15553    3230   12323   21%
total     31937   18723   13214   59%       -       0    -

 

help plz.

 

Rgds,

 

Morshed.

13 REPLIES
Dennis Handly
Acclaimed Contributor

Re: stack overflow

>getting below in dmesg output: HP-UX 11.31.

>Pid 13743 was killed due to failure in writing the signal context - possible stack overflow.

 

So what was PID 13743?  Do you have a corefile lying around?

And when was the dmesg error created?

 

 

mrmo07
Regular Advisor

Re: possible stack overflow

HI,

 

reconfigure "maxssiz" and its gone. seems problem resolve.

 

Regards,

 

Morshed.

Dennis Handly
Acclaimed Contributor

Re: stack overflow

>reconfigure "maxssiz" and it's gone.

 

What were the old and new values?

mrmo07
Regular Advisor

Re: possible stack overflow

this is current :

 

Tunable      Value  Expression  Changes
maxssiz  134217728  134217728   Immed

 

 

Rgds,

MOrshed

Dennis Handly
Acclaimed Contributor

Re: stack overflow

>this is current: 134,217,728

 

That's way too big unless you have some wacko recursive application.  Each byte here preallocated for the stack reduces the size of the heap, if maxdsiz already set to 1 GB.

mrmo07
Regular Advisor

Re: stack overflow

Hi ,

 

i'm getting the same again. not actually solved:

 

reapting in dmesg output:

 

 

Pid 27717 was killed due to failure in writing the signal context - possible stack overflow.

 

Regards,

Morshed.

Dennis Handly
Acclaimed Contributor

Re: stack overflow

You have to know what PID that was.  Any user complaining?

mrmo07
Regular Advisor

Re: stack overflow

 

Hi,

 

yes, when user compiling application  geeting problem.  plesae  see the attached part of dmesg and kmeminfo.  high memory use.

 

 

Regards,

Morshed.

Dennis Handly
Acclaimed Contributor

Re: stack overflow

>when user compiling application getting problem.

 

Do you have that error output?  Using gcc or aC++?

 

 >high memory use.

 

If you have high memory use, you need more swap.  What does "swapinfo -tam" show during this time?

I only add up to 59%.

mrmo07
Regular Advisor

Re: stack overflow

hi,

 

swap spece is avaiable.

 

root@dcpdb1 [/]# swapinfo -tam
             Mb      Mb      Mb   PCT  START/      Mb
TYPE      AVAIL    USED    FREE  USED   LIMIT RESERVE  PRI  NAME
dev       32768       0   32768    0%       0       -    1  /dev/vg00/lvol2
reserve       -   20843  -20843
memory    23345    5413   17932   23%
total     56113   26256   29857   47%       -       0    -
root@dcpdb1 [/]#

 

Regards,

 

Morshed.

Dennis Handly
Acclaimed Contributor

Re: stack overflow

>total     56113   26256   29857   47%

 

You're not short on memory at this time.

 

Have you looked for corefiles from the aborting process?

mrmo07
Regular Advisor

Re: stack overflow

hi,

 

but in the kmeminfo and glance showing high memory utillization: below is kmeminfo:

 

----------------------------------------------------------------------
Physical memory usage summary (in page/byte/percent):

Physical memory       =  6283593   24.0g 100%
Free memory           =   273898    1.0g   4%
User processes        =        0    0.0b   0%  details with -user
System                =       64  256.0k   0%
  Kernel              =        0    0.0b   0%  kernel text and data
    Dynamic Arenas    =   316354    1.2g   5%  details with -arena
      vm_alias_table_ =    35483  138.6m   1%
      vx_global_kmcac =    34806  136.0m   1%
      spinlock_arena  =    30899  120.7m   0%
      vm_pfn2v_arena  =    24920   97.3m   0%
      BTREE_NODE_OLA_ =    17575   68.7m   0%
      Other arenas    =   172671  674.5m   3%  details with -arena
    Super page pool   =   414552    1.6g   7%  details with -kas
    Static Tables     =   367482    1.4g   6%  details with -static
      pfdat           =   306816    1.2g   5%
      vhpt            =    32768  128.0m   1%
      text            =     9116   35.6m   0%  vmunix text section
      inode           =     7616   29.8m   0%
      bss             =     6762   26.4m   0%  vmunix bss section
      Other tables    =     4402   17.2m   0%  details with -static
  Buffer cache        =       30  120.0k   0%  details with -bufcache
  UFC file mrg        =  1196877    4.6g  19%
  UFC meta mrg        =       34  136.0k   0%

----------------------------------------------------------------------

Dennis Handly
Acclaimed Contributor

Re: stack overflow

>but in the kmeminfo and glance showing high memory utilization

 

I see 4.6 GB for file cache which will be freed if there is any memory pressure.