I have setup coreadm as follows
coreadm
global core file pattern: /var/core/core_%n_%f_%u_%g_%t_%p
global core file content: default
init core file pattern: /var/core/core_per_process_%n_%f_%u_%g_%t_%p
init core file content: default
global core dumps: enabled
per-process core dumps: enabled
global setid core dumps: enabled
per-process setid core dumps: enabled
global core dump logging: enabled
But no core file is being dumped from the application.
Any ideas as to how I can tell what process is exceeding the limit?
> My advice would be to set up coreadm to capture
> whichever process is
> doing this rather than guessing. [ This works on the
> assumption that the
> process is being sent a SEGV, and hence will dump
> core if so enabled. ]
>
> I would also advise against changing a global value
> for the sake of one
> (misbehaving?) application. I would much rather
> identify the process,
> then either log a bug (if this is errant behaviour),
> understand what
> configuration is necessary to reduce the stack usage,
> or provide a
> per-process change to the limit (i.e. a shell script
> wrapper to start
> the process) rather than blindly setting a global
> variable.
>
> My suspicion is that there is a recursive function
> somewhere which is
> consuming the stack segment, causing the limit to be
> reached and the
> process is terminated. Simply raising the limit will
> give it more
> headroom, but not actually move your problem further
> forward - the core
> dumps (if any) will simply be larger :-)
>
> Obviously this is speculation, but I would suggest
> coreadm (with global
> cores and core logging enabled) at least temporarily
> to catch the
> process. Searching the /var/svc/log files may also
> reveal a process
> which died unexpectedly, perhaps with the service
> simply restarting. If
> you suspect Xorg, then start with the cde-login or
> gdm SMF services to
> see if it reported anything there.
>
> Regards,
> Brian
>
>
> Mike DeMarco wrote:
> > Thanks for your post Brian:
> >
> > It is hard to tell what process is throwing this
> error as it is only displayed as the PID and since
> the process dies and svc watcher attempts to restart
> it the PID number changes.
> > >From /var/adm/messages around the time that this
> error is generated xorg is also trying to start. So
> My best guess is that it is xorg that wants more
> stack size.
> >
> > Is there a way to increase the global
> max-stack-size above its default of 10Meg?
> /etc/project does not do this. I have found that
> /etc/project is not working properly even under
> Solaris10u5 & u6, I am working this through Sun
> support now.
> >
> >
> >> I'm guessing here, but: the limit probably comes
> from
> >> the shell-imposed
> >> stack limit (default 10Mb / 10240Kb).
> >> This is normally put in place to catch bad apps or
> >> recursive functions
> >> that don't stop recursing. It helps stop one
> process
> >> quickly consuming
> >> vast amounts of RAM (OK, a simplistic approcach, I
> >> know).
> >>
> >> The question is - what is the app, and why does it
> >> need more than 10Mb
> >> for stack?
> >> If it really does need that much, then it may need
> to
> >> have the stack
> >> limit increased (perhaps a shell script wrapper
> with
> >> the appropriate
> >> "ulimit -s" command, or maybe there's a more
> clever
> >> way to do this now
> >> :-) ).
> >>
> >> One word of caution, especially for 32-bit
> processes:
> >> Don't be too
> >> liberal with the setting for the stack limit.
> Because
> >> of the location of
> >> stack and libraries within the process virtual
> >> address space, the stack
> >> limit effectively removes that amount of memory
> from
> >> the process. In a
> >> 32-bit process, only 4Gb is available, and setting
> >> the stack limit to
> >> 1Gb would actually only leave approx 3Gb for the
> >> process to use (despite
> >> the stack only being a few Kb in size).
> >>
> >> I would suggest looking at what the process is,
> and
> >> see whether there is
> >> a software fault there first, before fiddling with
> >> the stack limit.
> >> coreadm should help you catch what the process is
> (as
> >> out of stack
> >> generates SIGSEGV I believe) if you don't already
> >> know.
> >>
> >>
> >> Regards,
> >> Brian
> >>
> >>
> >>
>
> --
> Brian Ruthven
> Sun
> Microsystems UK
> Solaris Revenue Product Engineering Tel:
> +44 (0)1252 422 312
> Sparc House, Guillemont Park, Camberley, GU17 9QG
>
> _______________________________________________
> opensolaris-discuss mailing list
> opensolaris-discuss@opensolaris.org
--
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
