Hello,
I'm struggling with the following problem and I have no idea how to
solve it.
I'm testing an application which is running fine on a global zone,but
memory leaking when installed on a local zone.
The local zone has its whole root and a very simple, basic configuration:
bash-3.00# zonecfg
Edward Pilatowicz wrote:
- CALC_TABLE_ADDR() a little clunky. (it has seperate 32 and 64
versions, it assumes the syscall number is in eax/rax, and it has a
side effect of munging the syscall number.) how about defining just one
version of CALC_TABLE_ADDR() as:
---8---
#define
I've been thinking about how to manage delegated datasets in zones and
I keep thinking that it would be a good idea to allow datasets to be
aliased. As I've been looking at Ops Center 2.5, I see that zpools
that it creates are named by UUID (ugh!).
# zonecfg -z soltrain3 info zonepath
zonepath:
May I have 2 code reviewers for:
6911329 Incorrect code in kstat_delete causes panic
http://cr.opensolaris.org/~batschul/onnvkstat/
Description
A colleague was looking into a crash and the reason turned out to be a NULL
pointer dereference in kstat_delete():
kstat_delete(kstat_t *ksp)
{
Hey Ed, Steve, Jordan, Jerry,
I got it in writing from Veritas Engineering that they do not have any heartburn
over using fsck -o p on VxFS and inside the zone and also by testing in the
lab I
confirmed it behaves as expected and similar to UFS:
snip end
# uname -a
SunOS lab234 5.10
On Thu, Dec 17, 2009 at 09:39:34AM -0700, Jerry Jelinek wrote:
Edward Pilatowicz wrote:
- CALC_TABLE_ADDR() a little clunky. (it has seperate 32 and 64
versions, it assumes the syscall number is in eax/rax, and it has a
side effect of munging the syscall number.) how about defining just
lgtm.
ed
On Thu, Dec 17, 2009 at 07:34:08PM +0100, Frank Batschulat (Home) wrote:
Hey Ed, Steve, Jordan, Jerry,
I got it in writing from Veritas Engineering that they do not have any
heartburn
over using fsck -o p on VxFS and inside the zone and also by testing in the
lab I
confirmed it
On 12/17/09 10:17 AM, Frank Batschulat (Home) wrote:
May I have 2 code reviewers for:
6911329 Incorrect code in kstat_delete causes panic
http://cr.opensolaris.org/~batschul/onnvkstat/
Description
A colleague was looking into a crash and the reason turned out to be a NULL
pointer
I recommend using libumem on the application.
Some folks were nice enough to write about it.
http://blogs.sun.com/pnayak/entry/finding_memory_leaks_within_solaris
http://blogs.sun.com/dlutz/entry/memory_leak_detection_with_libumem
-Steve
On Thu, Dec 17, 2009 at 12:09:11PM +0200,
Yes. I already read this sites. The question is why on global zone there
isn't a memory leak and on local zone there is ?!
Steve Lawrence wrote:
I recommend using libumem on the application.
Some folks were nice enough to write about it.
As Steve said, libumem will be your best tool for this job.
Is the program zone-aware? The program might behave differently (i.e.,
its logic is different) while running in non-global zones and the
alternative code paths might be leaking memory.
Jordan
On 12/17/09 11:23 AM, Steve Lawrence
If you can provide some ::findleak details about the particular memory leak,
perhaps someone can help. Zones do not leak memory by design.
-Steve
On Thu, Dec 17, 2009 at 09:27:07PM +0200, AdinaKalin wrote:
Yes. I already read this sites. The question is why on global zone there
isn't a
This is exactly what I want to understand. No, the application is not
zones aware. My project is to certify
the application on zones.
Jordan Vaughan wrote:
As Steve said, libumem will be your best tool for this job.
Is the program zone-aware? The program might behave differently
(i.e., its
lgtm.
ed
On Thu, Dec 17, 2009 at 07:17:50PM +0100, Frank Batschulat (Home) wrote:
May I have 2 code reviewers for:
6911329 Incorrect code in kstat_delete causes panic
http://cr.opensolaris.org/~batschul/onnvkstat/
Description
A colleague was looking into a crash and the reason turned
On Thu 17 Dec 2009 at 01:58PM, Edward Pilatowicz wrote:
lgtm.
ed
On Thu, Dec 17, 2009 at 07:17:50PM +0100, Frank Batschulat (Home) wrote:
May I have 2 code reviewers for:
6911329 Incorrect code in kstat_delete causes panic
http://cr.opensolaris.org/~batschul/onnvkstat/
I noticed that you configured your zone with proc_lock_memory, so that
could explain the large RSS, but that would be same for the global zone too.
Before you start with libumem debugging, I would try ppriv(1) command
with the -D option to see if your app is silently failing because of a
Edward Pilatowicz wrote:
On Thu, Dec 17, 2009 at 09:39:34AM -0700, Jerry Jelinek wrote:
Edward Pilatowicz wrote:
- CALC_TABLE_ADDR() a little clunky. (it has seperate 32 and 64
versions, it assumes the syscall number is in eax/rax, and it has a
side effect of munging the syscall number.)
Frank Batschulat (Home) wrote:
Hey Ed, Steve, Jordan, Jerry,
I got it in writing from Veritas Engineering that they do not have any heartburn
over using fsck -o p on VxFS and inside the zone and also by testing in the
lab I
confirmed it behaves as expected and similar to UFS:
snip end
# uname
On Thu, Dec 17, 2009 at 04:24:22PM -0700, Jerry Jelinek wrote:
Edward Pilatowicz wrote:
to be:
---8---
/*
* The saved stack pointer (V_SSP) points to the interrupt specific
* state, which is saved directly above the stack contents common to all
* callbacks.
...
*/
#define V_U_SS
It would be useful to know if the memory leak is in locked memory or
not. What isthe output of the following command, in both cases (app in
GZ, app in a zone):
GZ# pmap -x pid
--JeffV
On Thu, Dec 17, 2009 at 5:09 AM, AdinaKalin
adina.kalin-flore...@sun.com wrote:
Hello,
I'm struggling with
20 matches
Mail list logo
