On Fri, Dec 18, 2009 at 1:12 PM, Chad Mynhier cmynh...@gmail.com wrote:
On Thu, Dec 17, 2009 at 3:08 PM, Hillel (Sabba) Markowitz
sabbahil...@gmail.com wrote:
On Wed, Dec 16, 2009 at 2:44 PM, Chad Mynhier cmynh...@gmail.com wrote:
#define STACKDEPTHBASE 2
I don't follow why this is set to
On Mon, Dec 21, 2009 at 8:47 AM, Hillel (Sabba) Markowitz
sabbahil...@gmail.com wrote:
When I tried to set up with a probe at
pid$target::main:entry with a printf inside it, I got no output.
However, I did get a main:return from
pid:target:hello::return
I do not understand why that is
Yes, a T5220.
S10, patch 141414-10
--
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
On Mon, Dec 21, 2009 at 07:19:35AM -0800, tester wrote:
Yes, a T5220.
You're printing the thread ID, which is good. But, suppose thre thread
in question gets re-scheduled on a different processor (or hw thread).
DTrace has a per-CPU trace log... You can see how such re-ordering
might happen
On Mon, Dec 21, 2009 at 9:45 AM, Chad Mynhier cmynh...@gmail.com wrote:
On Mon, Dec 21, 2009 at 8:47 AM, Hillel (Sabba) Markowitz
sabbahil...@gmail.com wrote:
When I tried to set up with a probe at
pid$target::main:entry with a printf inside it, I got no output.
However, I did get a
You're printing the thread ID, which is good. But,
suppose thre thread
in question gets re-scheduled on a different
processor (or hw thread).
DTrace has a per-CPU trace log... You can see how
such re-ordering
might happen :)
I am lost, I thought the probe was enabled on all CPU's.
Since DTrace buffers the information on a per-CPU basis, there's a chance on a
multi-sumpn system that the buffers may be consumed out of turn. Your exiting
stuff is recorded later, but every once in a while the buffer it was written to
is consumed first, and so it looks like the events
