Hi, I''m adding DTrace probes to MySQL and MySQL Cluster code and have some strange issues when building the dtrace .o file using the dtrace -G - s command. A subset of the collections I use are the following: probe start_acckeyreq(int op_ptr); probe end_acckeyreq(); probe start_acckeyreq_lockwait(void*, int); probe end_acckeyreq_lockwait(int op_ptr); The one that creates a problem is the start_acckeyreq_lockwait(void*, int); In the code this looks like the following: int int_val= operationRecPtr.i; void *ptr_val= operationRecPtr.p; jam(); signal->theData[0] = RNIL; NDB_BLOCKS_START_ACCKEYREQ_LOCKWAIT(ptr_val, int_val); return; When executing dtrace -G -s ndb_blocks_dtrace.d DbaccMain.o the output is (compilation of the cpp file goes fine: dtrace -G -s ndb_blocks_dtrace.d DbtupExecQuery.o DbtupCommit.o DbaccMain.o DbdihMain.o DbtcMain.o DblqhMain.o dtrace: failed to link script ndb_blocks_dtrace: an error was encountered while processing DbaccMain.o I haven''t figured out any way to get more information. By trial and error I''ve discovered that it is this probe that is the problem, but I don''t see any issue with it. I''ve also had other issues of similar kind with even simpler functions with only an int parameter. I don''t find any logic why the faulty ones are faulty and the correct ones are correct, any ideas would be helpful here. Rgrds Mikael Ronstrom -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080513/e9322a16/attachment.html>
Hi Trond, 13 maj 2008 kl. 12.08 skrev Trond Norbye:> Hi, > > I noticed your question on the mailing list. Could this be the same > problem I reported in CR 6672627 (code optimizer cause problems for > dtrace -G ). The problem is that you trigger a dtrace probe as the > last instruction in the function, and the compiler is tail- > optimizing the function call... A workaround for the problem is to > add statement below the dtrace probe... >You''re quite correct, I tried moving the faulty line one line up and it solved the issue. Thx. Rgrds Mikael> -- > Trond Norbye > > OPG, Database Technology Group E-mail: Trond.Norbye at Sun.Com > SUN Microsystems Phone: +47 73842100 > Haakon VII''s gt. 7B Fax: +47 73842101 > 7485 Trondheim, Norway > > > > On May 13, 2008, at 10:43 AM, Mikael Ronstr?m wrote: > >> Hi, >> I''m adding DTrace probes to MySQL and MySQL Cluster code and have >> some >> strange issues when building the dtrace .o file using the dtrace - >> G -s command. >> A subset of the collections I use are the following: >> >> probe start_acckeyreq(int op_ptr); >> probe end_acckeyreq(); >> probe start_acckeyreq_lockwait(void*, int); >> probe end_acckeyreq_lockwait(int op_ptr); >> >> The one that creates a problem is the start_acckeyreq_lockwait >> (void*, int); >> >> In the code this looks like the following: >> int int_val= operationRecPtr.i; >> void *ptr_val= operationRecPtr.p; >> jam(); >> signal->theData[0] = RNIL; >> NDB_BLOCKS_START_ACCKEYREQ_LOCKWAIT(ptr_val, int_val); >> return; >> >> When executing dtrace -G -s ndb_blocks_dtrace.d DbaccMain.o >> the output is (compilation of the cpp file goes fine: >> >> dtrace -G -s ndb_blocks_dtrace.d DbtupExecQuery.o DbtupCommit.o >> DbaccMain.o DbdihMain.o DbtcMain.o DblqhMain.o >> dtrace: failed to link script ndb_blocks_dtrace: an error was >> encountered while processing DbaccMain.o >> >> I haven''t figured out any way to get more information. By trial >> and error I''ve discovered that it is this probe that is the >> problem, but I don''t see any issue with it. I''ve also had other >> issues of similar kind with even simpler functions with only >> an int parameter. I don''t find any logic why the faulty ones are >> faulty and the correct ones are correct, any ideas would be >> helpful here. >> >> Rgrds Mikael Ronstrom >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-discuss at opensolaris.org >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080513/b6cbb026/attachment.html>
On Tue, May 13, 2008 at 10:43:36AM +0200, Mikael Ronstr?m wrote:> Hi, > I''m adding DTrace probes to MySQL and MySQL Cluster code and have some > strange issues when building the dtrace .o file using the dtrace -G - > s command. > A subset of the collections I use are the following: > > probe start_acckeyreq(int op_ptr); > probe end_acckeyreq(); > probe start_acckeyreq_lockwait(void*, int); > probe end_acckeyreq_lockwait(int op_ptr); > > The one that creates a problem is the start_acckeyreq_lockwait(void*, > int); > > In the code this looks like the following: > int int_val= operationRecPtr.i; > void *ptr_val= operationRecPtr.p; > jam(); > signal->theData[0] = RNIL; > NDB_BLOCKS_START_ACCKEYREQ_LOCKWAIT(ptr_val, int_val); > return; > > When executing dtrace -G -s ndb_blocks_dtrace.d DbaccMain.o > the output is (compilation of the cpp file goes fine: > > dtrace -G -s ndb_blocks_dtrace.d DbtupExecQuery.o DbtupCommit.o > DbaccMain.o DbdihMain.o DbtcMain.o DblqhMain.o > dtrace: failed to link script ndb_blocks_dtrace: an error was > encountered while processing DbaccMain.o > > I haven''t figured out any way to get more information. By trial and > error I''ve discovered that it is this probe that is the > problem, but I don''t see any issue with it. I''ve also had other > issues of similar kind with even simpler functions with only > an int parameter. I don''t find any logic why the faulty ones are > faulty and the correct ones are correct, any ideas would be > helpful here. > > Rgrds Mikael RonstromAdd -xdebug to the command-line and you may get some additional error message ... otherwise we can mail another DTrace script to dtrace dtrace and see what is going on in there :) -Mike -- Mike Shapiro, Sun Microsystems Fishworks. blogs.sun.com/mws/