This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: uprobe.ko is resident in memory.


On Mon, 2009-03-16 at 12:11 +0100, Mark Wielaard wrote:
> Hi Wenji,
> 
> On Mon, 2009-03-16 at 14:09 +0800, Wenji Huang wrote:
> > In user-space probing, the uprobe module will be
> > resident in memory even the stap exists.

s/exists/exits/ -- right?

> > 
> > [wjhuang@F10-32bits systemtap]$ /sbin/lsmod|grep uprobe
> > [wjhuang@F10-32bits systemtap]$ sudo stap -e 'probe 
> > process("/home/wjhuang/Download/git-1.5.6/git").function("main"){}'
> > WARNING: side-effect-free probe 'probe_1383': keyword at <input>:1:1
> >   source: probe 
> > process("/home/wjhuang/Download/git-1.5.6/git").function("main"){}
> >           ^
> > ^C[wjhuang@F10-32bits systemtap]/sbin/lsmod|grep uprobe
> > uprobes                24176  0
> >
> > Is this on purpose or some specific consideration?
> 
> I believe it is a bug caused by the way we build uprobes on the fly
> resulting in several oddities when using uprobe based scripts. 

Once uprobes.ko is loaded, it stays loaded.  It's the intended behavior.
There are circumstances where uprobes.ko has to stay loaded long after
you want stap/staprun/stapio to exit -- for example, if you have a
return probe on a function that's not going to return any time soon.
Then there are the concurrency issues that would arise when multiple
instances of stap are trying to load or unload uprobes.ko.  I don't
really see any reason to take on this additional complexity.

> 
> Cheers,
> 
> Mark
> 

Jim


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]