Re: PR3498: more efficient dwfl searching

[Wenji Huang <wenji dot huang at oracle dot com>]

Wenji Huang wrote:
> Frank Ch. Eigler wrote:
> > Hi -
> >
> > I committed some code to dramatically improve the pass-2 and pass-3
> > processing times for scripts that target the kernel, especially for
> > kernel build trees that have oodles of files under
> > /lib/modules/.../build.  It's basically using the offline module
> > search function's predicate vigorously, so that stap doesn't bother
> > open all .ko's on the system just for a kernel probe.
> >
> > My early testing shows no problems, just speedups, but if you notice
> > debuginfo being found less well than before, please let me know.
> >
> > - FChE
> I found one regression since this commit.
>
> $ stap -l nfsd.create*
> Segmentation fault
> [78375.044067] <6>stap[24911]: segfault at 0 ip 0000000000480efb sp 
> 00007ffffe706400 error 4 in stap[400000+142000]
>
> In fact, nfsd.create* includes nfsd.create and nfsd.createv3. In my
> machine,
> $ stap -l nfsd.create
> nfsd.create
> $ stap -l nfsd.createv3
> semantic error: no match while resolving probe point nfsd.createv3
>
> But nfsd.create* will get the error. Gdb said
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 140517345056560 (LWP 24971)]
> base_query (this=0x7fffd6b68950, dw=@0x0, params=@0x7fffd6b68b40) at 
> tapsets.cxx:442
> 442       sess(dw.sess), dw(dw)
>
> If nfsd.createv3 existed in the kernel, there will be OK.
>
> Regards,
> Wenji
Seems that checking dw can resolve the error. Did some tests, work fine.

diff --git a/tapsets.cxx b/tapsets.cxx
index 9ca25b0..71dd0d9 100644
--- a/tapsets.cxx
+++ b/tapsets.cxx
@@ -3457,6 +3457,9 @@ dwarf_builder::build(systemtap_session & sess,
   if (sess.verbose > 3)
     clog << "dwarf_builder::build for " << module_name << endl;

+  if(!dw)
+    return;
+
   string mark_name;
   if (get_param(parameters, TOK_MARK, mark_name))
     {

Regards,
Wenji