Re: [dtrace-discuss] application is not getting started with dvm options.
You don't need to modify your LD_LIBRARY_PATH, just copy the files to the correct location. For example on a 32-bit JVM on x86 you'd do: cp build/i386/lib/libdvmti.so /usr/java/jre/lib/i386/ cp build/i386/lib/dvmti.jar /usr/java/jre/lib/i386/ If you use truss to run your java -Xrundvmti:help command you can see all the locations that are being searched. -- This message posted from opensolaris.org ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
[dtrace-discuss] DTrace and Java 1.4/1.5
I've created an updated version of the dvm agents that I'm making available for download. See the changelog on the download site. I've also ported the hotspot scripts from the DTraceToolkit-0.99 to the dvm providers. There are a handful of other dvm scripts there for download. Comments welcome. http://www.osdev.org/dtrace/ -- This message posted from opensolaris.org ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] listing USDT probes, if any
Adam Leventhal wrote: > On Tue, Jan 29, 2008 at 10:47:57PM -0500, Angelo Rajadurai wrote: >> It would be wonderful to have dtrace -l -n *1234::: show all the pid >> probes. > > I should have been clearer. Today, that will show existing pid probes. > After the fix it will _create_ new pid probes so *1234::: will fail as it > tries to create a probe for every instruction in the process. > > It seems like it would be useful to be able to view the USDT probes for > a non-running executable. What do people think? I think it would be useful (especially for applications that can't start), and it would be cool if it were as parallel as possible for running vs. not-running applications. DTrace is a very "discover things without knowing anything"-capable application, so "a list of probes and providers" may be the secret to narrowing down a behavior in something for which you don't have source or experience. ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] listing USDT probes, if any
> Along those lines, though, it feels like the dtrace command might > be getting a bit overloaded. > > I'm sure I'm forgetting some, but I know dtrace is at least a linker, > a header file generator, a compiler, and now possibly an object file > parser with DOF pretty printing. We often joked that we were reimplementing all of computing inside of the DTrace framework. > Is there any thinking of splitting these functions into separate > commands? Never! Or at least not until we're forced to use unicode command-line options. Though users or ports should feel free to sequester specific functionality in simple wrapper scripts. Adam -- Adam Leventhal, Fishworkshttp://blogs.sun.com/ahl ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Truning on pid$target probes hangs Solaris
I'd suggest trying to connect with the Parallels folks to see if they can tell you where we are in the Solaris kernel. I'd also suggest that VMware Fusion might be a better virtualization option. That's not to say we haven't has issues with VMware, but they have been very helpful in diagnosing problems and helping us solve them: http://blogs.sun.com/ahl/entry/debugging_cross_calls_on_opensolaris Adam On Wed, Jan 30, 2008 at 05:06:08PM -0500, Angelo Rajadurai wrote: > Hi: > > I'm running Indiana (OpenSolaris developer preview) under parallels > in OS X 10.5.1. I can consistently get Solaris to hang. > > Doing a > dtrace -n pid\$target::malloc:entry'[EMAIL PROTECTED]()}' -c ls > > will consistently hang Solaris. > > Basically doing anything with PID provider with the > -c option seems to hangs Solaris. Only way to recover > is to stop and start Parallels desktop. > > The same D one liner on a running process works just fine. (ie) > dtrace -n pid1234::malloc:entry'[EMAIL PROTECTED]()}' has no problem. > > I tried to look at Parallels during the hang using pid provider in > OS X and I see it is doing a bunch of ioctl's on /dev/vm-main > > From within Solaris if I start dtrace under truss, then I find the last > thing truss was able to record is a bunch of preads. I have the > output from truss if anyone is interested. (its 180K) > > This could not have happened at the worse time. I was before > an important ISV showing off DTrace and how stable it is and > it hangs on me! > > Any help on debugging this would be great. > > Thanks > > Angelo > > ___ > dtrace-discuss mailing list > dtrace-discuss@opensolaris.org -- Adam Leventhal, Fishworkshttp://blogs.sun.com/ahl ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] listing USDT probes, if any
On Jan 30, 2008, at 11:19 AM, Adam Leventhal wrote: > On Wed, Jan 30, 2008 at 11:05:04AM -0800, James McIlree wrote: >> We've had several requests for this feature. >> >> An interesting question we've debated is should such >> a feature include probes from libraries? >> >> I.E, user does: >> >> dtrace_list_probes ./someApplicationTheyCareAbout >> >> they get: >> >> "Zero probes found" >> >> but they expected to see at least plockstat probes, >> maybe some CoreData probes, and so on. > > It seems like we should probably navigate the library dependencies > -- good > point. > > If you're already thinking about working on this, that would be > great, but > please send out a proposal before you squat on a particular option > character > as we have some plans for various ones... Not to worry, I'm positive I won't have time to look at this soon :-). Along those lines, though, it feels like the dtrace command might be getting a bit overloaded. I'm sure I'm forgetting some, but I know dtrace is at least a linker, a header file generator, a compiler, and now possibly an object file parser with DOF pretty printing. Is there any thinking of splitting these functions into separate commands? James M ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
[dtrace-discuss] Truning on pid$target probes hangs Solaris
Hi: I'm running Indiana (OpenSolaris developer preview) under parallels in OS X 10.5.1. I can consistently get Solaris to hang. Doing a dtrace -n pid\$target::malloc:entry'[EMAIL PROTECTED]()}' -c ls will consistently hang Solaris. Basically doing anything with PID provider with the -c option seems to hangs Solaris. Only way to recover is to stop and start Parallels desktop. The same D one liner on a running process works just fine. (ie) dtrace -n pid1234::malloc:entry'[EMAIL PROTECTED]()}' has no problem. I tried to look at Parallels during the hang using pid provider in OS X and I see it is doing a bunch of ioctl's on /dev/vm-main From within Solaris if I start dtrace under truss, then I find the last thing truss was able to record is a bunch of preads. I have the output from truss if anyone is interested. (its 180K) This could not have happened at the worse time. I was before an important ISV showing off DTrace and how stable it is and it hangs on me! Any help on debugging this would be great. Thanks Angelo ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Help on refining pid probe in a multi-threaded process
Adam, In conclusion to this thread: 1) Absolute addressing ---caution well noted when using it. The pid$target::-: has Dtrace compile problems. The Dtrace compiler output: Failed to compile script o2debug4.d: line 62: extraneous argument '9364' ($1 is not referenced). As I can work around using offsets I do not want to waste your time on this one. 2) my stupidity on local verses global predicate variables to fire all threads within the pid --- thk u for the lesson 3) as below, my learning refinement on how-to-play-with defining offsets to get them to fire. noting your debugging approach allows me to home the offset definition. Now i can get them to fire under my control to refine the bug-watch. Thk u for your help and thread closed:} Sincerely Dave On Wednesday, January 30, 2008, at 10:11AM, "Adam Leventhal" <[EMAIL PROTECTED]> wrote: >On Tue, Jan 29, 2008 at 09:25:59PM -0500, david bone wrote: >> >It looks like there's likely no instruction at offset 0x291; how >> >did you >> >get that address? >> > >> The address was obtained using dbx from sunstudio12. Please see the >> attachment `disassembly` showing the complete disassembled code for >> the get_next_token function. Below is the extracted disassembled >> instruction probed on. >> __1cGyacco2GParserOget_next_token6M_pn0AMCAbs_lr1_sym__+0x291: >> movl $0x0,-0x24(%rbp) >> Unfortunately the instruction exists. Here's your request piped thru >> mdb. > >The problem is that you need to specify the probe like this: > > pid$target::__1cGyacco2GParserOget_next_token6M_pn0AMCAbs_lr1_sym__:291 > >Adam > >-- >Adam Leventhal, Fishworkshttp://blogs.sun.com/ahl > > ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] listing USDT probes, if any
On Wed, Jan 30, 2008 at 11:05:04AM -0800, James McIlree wrote: > We've had several requests for this feature. > > An interesting question we've debated is should such > a feature include probes from libraries? > > I.E, user does: > > dtrace_list_probes ./someApplicationTheyCareAbout > > they get: > > "Zero probes found" > > but they expected to see at least plockstat probes, > maybe some CoreData probes, and so on. It seems like we should probably navigate the library dependencies -- good point. If you're already thinking about working on this, that would be great, but please send out a proposal before you squat on a particular option character as we have some plans for various ones... - ahl -- Adam Leventhal, Fishworkshttp://blogs.sun.com/ahl ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] listing USDT probes, if any
On Jan 30, 2008, at 10:08 AM, Adam Leventhal wrote: > On Tue, Jan 29, 2008 at 10:47:57PM -0500, Angelo Rajadurai wrote: >> It would be wonderful to have dtrace -l -n *1234::: show all the pid >> probes. > > I should have been clearer. Today, that will show existing pid probes. > After the fix it will _create_ new pid probes so *1234::: will fail > as it > tries to create a probe for every instruction in the process. > > It seems like it would be useful to be able to view the USDT probes > for > a non-running executable. What do people think? We've had several requests for this feature. An interesting question we've debated is should such a feature include probes from libraries? I.E, user does: dtrace_list_probes ./someApplicationTheyCareAbout they get: "Zero probes found" but they expected to see at least plockstat probes, maybe some CoreData probes, and so on. James M ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Help on refining pid probe in a multi-threaded process
On Tue, Jan 29, 2008 at 09:25:59PM -0500, david bone wrote: > >It looks like there's likely no instruction at offset 0x291; how > >did you > >get that address? > > > The address was obtained using dbx from sunstudio12. Please see the > attachment `disassembly` showing the complete disassembled code for > the get_next_token function. Below is the extracted disassembled > instruction probed on. > __1cGyacco2GParserOget_next_token6M_pn0AMCAbs_lr1_sym__+0x291: > movl $0x0,-0x24(%rbp) > Unfortunately the instruction exists. Here's your request piped thru > mdb. The problem is that you need to specify the probe like this: pid$target::__1cGyacco2GParserOget_next_token6M_pn0AMCAbs_lr1_sym__:291 Adam -- Adam Leventhal, Fishworkshttp://blogs.sun.com/ahl ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] listing USDT probes, if any
On Tue, Jan 29, 2008 at 10:47:57PM -0500, Angelo Rajadurai wrote: > It would be wonderful to have dtrace -l -n *1234::: show all the pid > probes. I should have been clearer. Today, that will show existing pid probes. After the fix it will _create_ new pid probes so *1234::: will fail as it tries to create a probe for every instruction in the process. It seems like it would be useful to be able to view the USDT probes for a non-running executable. What do people think? Adam -- Adam Leventhal, Fishworkshttp://blogs.sun.com/ahl ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Help on refining pid probe in a multi-threaded process
Adam, Thk u on the absolute address how-to for a pid probe, and link to refine my Dtrace fluency. > >Curious. I'm surprised that it's not letting you instrument that >instruction. Show me this output: > >dtrace -l -n pid::__1cGyacco2GParserOget_next_token6M_pn0AMCAbs_lr1_sym__: > The attached file `disassembly2` contains the output showing the entry,return probes with the instrumented instruction . Dave disassembly2 Description: Binary data ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] copyin not giving expected result
Hi Tiller,
> If you dereference A does it give you what you want?
>
> Try this (see the extra * added in the second printf ):
>
> $ dtrace -32 -w -n 'pid14243::mutt_iconv:entry{printf("0x%x ", arg1);
> A=copyin(arg1,4); printf("0x%x ", *((unsigned int)A)); stop();}'
Yes, this is exactly where I made the mistake. copyin is returning
pointer to the 'scratch' space, and not the buffer content itself.
For the reference, the function looks like
pid$target::mutt_iconv:entry
{
A=*(unsigned int*)copyin(arg1,4);
printf("0x%x ", A); trace(copyinstr(A));
}
> .tiller
Thank you Tiller
--
Vlad
pgpqSUpk9SBF2.pgp
Description: PGP signature
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
[dtrace-discuss] copyin not giving expected result
Hi,
I'm having C function
size_t mutt_iconv (iconv_t cd, char **inbuf, ...
I would like to print the inbuf using dtrace.
I was thinking to use something like
"PTR=copyin(arg1, 4); trace(copyinstr(PTR));" but it does not work for
me.
$ dtrace -32 -w -n 'pid14243::mutt_iconv:entry{printf("0x%x ", arg1);
A=copyin(arg1,4); printf("0x%x ", ((unsigned int)A)); stop();}'
dtrace: description 'pid14243::mutt_iconv:entry' matched 1 probe
dtrace: allowing destructive actions
CPU IDFUNCTION:NAME
0 75510 mutt_iconv:entry 0x8045168 0x97aa7018
^C
However if I try to dereference the pointer in mdb:
pub 12:54 ~/test: mdb -p 14243
Loading modules: [ ld.so.1 libc.so.1 ]
> 0x8045168/X
0x8045168: 8e4c038
>
I get correct resutl 8e4c038. I'm a bit confused, what am I doing wrong ?
And alternatively, is there better way of getting char **inbuf, than twhice
manually copyin ?
Thanks
--
Vlad
pgpRvToYSACtH.pgp
Description: PGP signature
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Solaris Dynamic Tracing Guide gets Wikified!
Hi Max, Feel free to look at both! The wiki should offer slightly more up to date content than the docs.sun.com version but the changes on the wiki should trickle through to the docs.sun.com version. The MDB guide on the wiki isn't quite finished yet so you really should stick to the docs.sun.com version until I find the time to finish it. Jon. > Hi All, > Now that the dtrace guide has been wikified, what happens with the guide > on docs.sun.com? > Should I look at the wikified guide, or the (dated) guide on > docs.sun.com? I have the same question > about the Modular Debugger guide. Also, any chance of changing the > dashboard page to > include MDB with the "Solaris Modular Debugger" line? I went to > wikis.sun.com and searched the page > for mdb and didn't find it. Then I searched for debug and there it was. > > thanks, > max > > Adam Leventhal wrote: > >> Agreed. We were thinking of doing exactly this. The provider chapters would >> be a great place to start. There should be a table in each describing the >> support on various platforms as well as any usage notes which might apply. >> >> Adam >> >> On Thu, Dec 13, 2007 at 10:37:01AM -0500, Jim Mauro wrote: >> >> >>> Great question. As a dtrace user and documentation reader, I would not >>> want to >>> need to flip to another chapter, or another section, to read about >>> platform differences >>> for a particular provider, function, etc. I'm not saying you suggested >>> that, I'm just >>> thinking out loud... >>> >>> I think a reasonable way to do this, and maintain consistency, is to add >>> a "Platform Notes" >>> heading to each section - or perhaps at a Chapter granularity. >>> >>> Within Platform Notes, we have subsections for "Mac OS X", "FreeBSD", etc, >>> and add the platform specific notes there. >>> >>> It may also be useful to add a chapter that discusses platform >>> differences at a >>> high level. >>> >>> Just some thoughts...if the platform differences are not vast enough to >>> warrant >>> adding format changes to the document, perhaps they can be handled in >>> footnotes. >>> (keeping in mind footnotes are considered poor writing style). >>> >>> Thanks, >>> /jim >>> >>> >>> Quinn wrote: >>> >>> At 10:23 -0800 28/11/07, Adam Leventhal wrote: > On Tue, Nov 27, 2007 at 07:46:37PM +, Jon Haslam wrote: > > > >> To gain access to the DTrace wiki space contact Adam >> ([EMAIL PROTECTED]). If you are working on a bug >> from the bug list make sure you update the owner column of >> the bug to reflect the fact. When you've finished please >> update the column in the bug list to reflect that fact. >> >> >> > Actually, there's no need to contact me or anyone: the wiki is open for > all > registered users to modify. We'll tighted up security if we have any > problems. > > > How do you want to handle platform-specific changes? As I stumble across Mac OS X specific stuff, I'd like to add it to the book. To me that makes a lot more sense that maintaining a separate "DTrace on Mac OS X" document. For example, the discussion of the "stop" action says that you can start a process using "prun", but that's not available on Mac OS X. On Mac OS X you can use "kill -CONT ". I'd love to just go in there and add a note to that effect, but I figured I'd ask about formatting conventions first. S+E >>> ___ >>> dtrace-discuss mailing list >>> dtrace-discuss@opensolaris.org >>> >>> >> >> > > ___ > dtrace-discuss mailing list > dtrace-discuss@opensolaris.org > ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Solaris Dynamic Tracing Guide gets Wikified!
Hi All, Now that the dtrace guide has been wikified, what happens with the guide on docs.sun.com? Should I look at the wikified guide, or the (dated) guide on docs.sun.com? I have the same question about the Modular Debugger guide. Also, any chance of changing the dashboard page to include MDB with the "Solaris Modular Debugger" line? I went to wikis.sun.com and searched the page for mdb and didn't find it. Then I searched for debug and there it was. thanks, max Adam Leventhal wrote: > Agreed. We were thinking of doing exactly this. The provider chapters would > be a great place to start. There should be a table in each describing the > support on various platforms as well as any usage notes which might apply. > > Adam > > On Thu, Dec 13, 2007 at 10:37:01AM -0500, Jim Mauro wrote: > >> Great question. As a dtrace user and documentation reader, I would not >> want to >> need to flip to another chapter, or another section, to read about >> platform differences >> for a particular provider, function, etc. I'm not saying you suggested >> that, I'm just >> thinking out loud... >> >> I think a reasonable way to do this, and maintain consistency, is to add >> a "Platform Notes" >> heading to each section - or perhaps at a Chapter granularity. >> >> Within Platform Notes, we have subsections for "Mac OS X", "FreeBSD", etc, >> and add the platform specific notes there. >> >> It may also be useful to add a chapter that discusses platform >> differences at a >> high level. >> >> Just some thoughts...if the platform differences are not vast enough to >> warrant >> adding format changes to the document, perhaps they can be handled in >> footnotes. >> (keeping in mind footnotes are considered poor writing style). >> >> Thanks, >> /jim >> >> >> Quinn wrote: >> >>> At 10:23 -0800 28/11/07, Adam Leventhal wrote: >>> >>> On Tue, Nov 27, 2007 at 07:46:37PM +, Jon Haslam wrote: > To gain access to the DTrace wiki space contact Adam > ([EMAIL PROTECTED]). If you are working on a bug > from the bug list make sure you update the owner column of > the bug to reflect the fact. When you've finished please > update the column in the bug list to reflect that fact. > > Actually, there's no need to contact me or anyone: the wiki is open for all registered users to modify. We'll tighted up security if we have any problems. >>> How do you want to handle platform-specific changes? As I stumble >>> across Mac OS X specific stuff, I'd like to add it to the book. To >>> me that makes a lot more sense that maintaining a separate "DTrace on >>> Mac OS X" document. >>> >>> For example, the discussion of the "stop" action says that you can >>> start a process using "prun", but that's not available on Mac OS X. >>> On Mac OS X you can use "kill -CONT ". I'd love to just go in >>> there and add a note to that effect, but I figured I'd ask about >>> formatting conventions first. >>> >>> S+E >>> >>> >> ___ >> dtrace-discuss mailing list >> dtrace-discuss@opensolaris.org >> > > ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
