Hola, I am trying to isolate the memory leak I suspect in a mailman
installation I found:
http://blogs.sun.com/sanjeevb/date/200506
It gives an error:
[EMAIL PROTECTED]:~ 9:21am 65 # ./memleak.d 10312
dtrace: failed to compile script ./memleak.d: line 3: probe description
pid10312:libc.so.1:mal
Fletcher Cocquyt wrote:
> Hola, I am trying to isolate the memory leak I suspect in a mailman
> installation – I found:
> http://blogs.sun.com/sanjeevb/date/200506
>
> It gives an error:
>
> [EMAIL PROTECTED]:~ 9:21am 65 # ./memleak.d 10312
> dtrace: failed to compile script ./memleak.d: line 3:
Yes:
[EMAIL PROTECTED]:~ 10:02am 52 # ps -ef | grep 10312
mailman 10312 22726 0 09:13:19 ? 0:05 /bin/python
/opt/mailman-2.1.9/bin/qrunner --runner=VirginRunner:0:1 -s
This is the error for no such process:
[EMAIL PROTECTED]:~ 10:04am 53 # ./memleak.d 666
dtrace: failed to compile sc
Fletcher Cocquyt wrote:
> Yes:
> [EMAIL PROTECTED]:~ 10:02am 52 # ps -ef | grep 10312
> mailman 10312 22726 0 09:13:19 ? 0:05 /bin/python
> /opt/mailman-2.1.9/bin/qrunner --runner=VirginRunner:0:1 -s
oh ... I hadn't realised you were talking about python.
I seem to remember that ther
Hi,
I have written a device driver for an own PCI card reading bytes from a process
signal frame.
The driver is running quite well (2,4 GHz dual Core) reading one byte is done
in about 4 microseconds.
The problem is, that sometimes the read of one byte need up to 80 microseconds.
The driver uses
Siegfried Schmidt wrote:
> Hi,
> I have written a device driver for an own PCI card reading bytes from a
> process signal frame.
> The driver is running quite well (2,4 GHz dual Core) reading one byte is done
> in about 4 microseconds.
> The problem is, that sometimes the read of one byte need up
Hello,
> I can't really comment on when it will be fixed, but in general I would
> hazard a guess
> that this doesn't rise to the level of impact that would allow it to
> be included with a 10.x.xrelease. I've been wrong before, YMMV, not
Odd, under 10.5.3 I can't get 'string' to work either,
Hello Fletcher,
From the error looks like dtrace is not able recognize it as probe.
DTrace needs a signature for the function to be detected as probe.
Probably this is missing in case of malloc.
Just to double check this you could disassemble malloc and check if we
have a "push' instruction at t
On Jul 1, 2008, at 9:16 PM, Domas Mituzas wrote:
> Hello,
>
>> I can't really comment on when it will be fixed, but in general I
>> would hazard a guess
>> that this doesn't rise to the level of impact that would allow it to
>> be included with a 10.x.xrelease. I've been wrong before, YMMV, not
Helloes,
> String is a 'D' type, not a C type. Long story short, you want to use char*,
> not string.
Oki, thats what I thought - though now I have to use lots of copyinstr()s.
Interesting though, I ended up porting some dtrace hooks (in stuff like php
pecl's dtrace) from solaris to macosx.
T
On Jul 1, 2008, at 10:57 PM, Domas Mituzas wrote:
> Helloes,
>
>> String is a 'D' type, not a C type. Long story short, you want to
>> use char*, not string.
>
> Oki, thats what I thought - though now I have to use lots of
> copyinstr()s.
>
> Interesting though, I ended up porting some d
Can you please provide a reference for disassembling malloc on Solaris 10?
I am also pursuing the previous suggestion of a Python provider - this one
seems to be against Python 2.5:
http://blogs.sun.com/binujp/resource/pydtrace/diffs
Thanks,
Fletcher
On 7/1/08 9:48 PM, "Sanjeev Bagewadi" <[EMAIL
12 matches
Mail list logo
