[Click] SpinlockInfo Help

springbo at cs.wisc.edu springbo at cs.wisc.edu
Mon Aug 4 18:17:33 EDT 2008


Hi,

When trying to track down a x86_64 concurrency bug, I came across problems
using SpinlockInfo, SpinlockAcquire, and SpinlockRelease. My test script
is attached. The resulting segfault backtrace is:

0x00000000004c5353 in Spinlock::acquire (this=0x0)
    at ../include/click/sync.hh:108
108         if (_owner != click_current_processor()) {
(gdb) where
#0  0x00000000004c5353 in Spinlock::acquire (this=0x0)
    at ../include/click/sync.hh:108
#1  0x000000000057af0b in SpinlockAcquire::simple_action (this=0x8d53e0,
    p=0x8dac00) at ../elements/threads/spinlockacquire.hh:30
#2  0x00000000005b8a5f in Element::push (this=0x8d53e0, port=0, p=0x8dac00)
    at ../lib/element.cc:2585
#3  0x000000000049a900 in Element::Port::push (this=0x8d4ec8, p=0x8dac00)
    at ../include/click/element.hh:545
#4  0x00000000005728cb in Unqueue::run_task (this=0x8d4ea0)
    at ../elements/standard/unqueue.cc:71
#5  0x00000000005ca57f in Task::fire (this=0x8d4f18)
    at ../include/click/task.hh:542
#6  0x00000000005ca795 in RouterThread::run_tasks (this=0x8d0380, ntasks=122)
    at ../lib/routerthread.cc:386
#7  0x00000000005ca35c in RouterThread::driver (this=0x8d0380)
    at ../lib/routerthread.cc:540
#8  0x00000000005a715d in main (argc=2, argv=0x7fffe0d3d758) at click.cc:546

I am running a multithreaded x86_64 installation built on the master cvs
sources from about three weeks ago. From the backtrace you'll notice
SpinlockAcquire::_lock = 0.

My understanding of what is going on:

Line 41 of spinlockinfo.cc:
>>>>>>     ndb->define(name, &_spinlocks.back(), sizeof(Spinlock *));
calls DynamicNameDB::define with the name, a pointer to the Spinlock, and
the size of the Spinlock pointer

Line 268 of nameinfo.cc:
>>>>>>     memcpy(x, value, vsize);
copies the first 8 bytes of the Spinlock into the value of x (The first 8
bytes of Spinlock should be _lock(0) and _depth(0) or NULL if viewed as a
pointer)

Line 28 of spinlockacquire.cc:
>>>>>>     if (!NameInfo::query(NameInfo::T_SPINLOCK, this, name, &_lock,
sizeof(Spinlock *)))
Line 226 of nameinfo.cc (in the query function):
>>>>>>     memcpy(value, x, vsize);
the argument _lock is set to the first 8 bytes of the spinlock (which have
a value of 0).

Finally when the _lock is used the pointer with a value of NULL is
dereferenced. Resulting in a seg fault (or worse if running as a module).


Sorry I didn't come up with a patch, but I couldn't come up with an easy
fix without changing the way the elements work.

Could anyone verify they can use the Spinlock elements? Or possibly point
out the flaw in my logic above?

Thanks,
Kevin Springborn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: threading.click
Type: application/octet-stream
Size: 587 bytes
Desc: not available
Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20080804/b4d66f10/attachment.obj 


More information about the click mailing list