locking timeout error ?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

locking timeout error ?

Badari Pulavarty
What does this mean ?

 # stap  -g topsys.stp
ERROR: locking timeout over variable global_syscalls_count near
identifier 'syscalls_count' at topsys.stp:27:2

Thanks,
Badari


Reply | Threaded
Open this post in threaded view
|

Re: locking timeout error ?

Martin Hunt
On Fri, 2006-01-06 at 15:25 -0800, Badari Pulavarty wrote:
> What does this mean ?
>
>  # stap  -g topsys.stp
> ERROR: locking timeout over variable global_syscalls_count near
> identifier 'syscalls_count' at topsys.stp:27:2

You've found a bug.

If you are saving stats in a map, then trying to print them, you have
probably hit http://sourceware.org/bugzilla/show_bug.cgi?id=2056

Otherwise, can you post some source which shows what you are doing?

Martin



Reply | Threaded
Open this post in threaded view
|

RE: locking timeout error ?

Stone, Joshua I
In reply to this post by Badari Pulavarty
Martin Hunt wrote:

> On Fri, 2006-01-06 at 15:25 -0800, Badari Pulavarty wrote:
>> What does this mean ?
>>
>>  # stap  -g topsys.stp
>> ERROR: locking timeout over variable global_syscalls_count near
>> identifier 'syscalls_count' at topsys.stp:27:2
>
> You've found a bug.
>
> If you are saving stats in a map, then trying to print them, you have
> probably hit http://sourceware.org/bugzilla/show_bug.cgi?id=2056
>
> Otherwise, can you post some source which shows what you are doing?
>
> Martin

This is in CVS: tests/testsuite/systemtap.samples/topsys.stp

In fact the problem here is that the script is *not* using stats - it's
incrementing a counter in a global array.  So Badari must be running on
an SMP machine, and two threads are trying to access the array at the
same time.

A few days ago Frank checked in code to let it wait longer to attain a
lock, so you might have better luck with a newer CVS build.

I would suggest that we should convert that script to use stats, but as
Martin points out, it's also buggy right now.


Josh

Reply | Threaded
Open this post in threaded view
|

RE: locking timeout error ?

Martin Hunt
On Fri, 2006-01-06 at 16:37 -0800, Stone, Joshua I wrote:
> This is in CVS: tests/testsuite/systemtap.samples/topsys.stp
>
> In fact the problem here is that the script is *not* using stats - it's
> incrementing a counter in a global array.  So Badari must be running on
> an SMP machine, and two threads are trying to access the array at the
> same time.
>
> A few days ago Frank checked in code to let it wait longer to attain a
> lock, so you might have better luck with a newer CVS build.

I should have recognized the name. As you point out that bug was fixed a
few days ago. topsys runs fine on a quad-processor machine for me.

Martin



Reply | Threaded
Open this post in threaded view
|

RE: locking timeout error ?

Badari Pulavarty
In reply to this post by Stone, Joshua I
On Fri, 2006-01-06 at 16:37 -0800, Stone, Joshua I wrote:

> Martin Hunt wrote:
> > On Fri, 2006-01-06 at 15:25 -0800, Badari Pulavarty wrote:
> >> What does this mean ?
> >>
> >>  # stap  -g topsys.stp
> >> ERROR: locking timeout over variable global_syscalls_count near
> >> identifier 'syscalls_count' at topsys.stp:27:2
> >
> > You've found a bug.
> >
> > If you are saving stats in a map, then trying to print them, you have
> > probably hit http://sourceware.org/bugzilla/show_bug.cgi?id=2056
> >
> > Otherwise, can you post some source which shows what you are doing?
> >
> > Martin
>
> This is in CVS: tests/testsuite/systemtap.samples/topsys.stp
>
> In fact the problem here is that the script is *not* using stats - it's
> incrementing a counter in a global array.  So Badari must be running on
> an SMP machine, and two threads are trying to access the array at the
> same time.
>
> A few days ago Frank checked in code to let it wait longer to attain a
> lock, so you might have better luck with a newer CVS build.
>
> I would suggest that we should convert that script to use stats, but as
> Martin points out, it's also buggy right now.

Yes. Latest version seems to be working fine. (Of course, I had to use
Hien's patch for get_user_asm() to make it compile).

Thanks,
Badari