[Click] SpinlockInfo Help

[Eddie Kohler]

Hi Kevin,

Thanks for this bug report -- the fix is in.  Sorry!

Eddie


springbo at cs.wisc.edu wrote:
> 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
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click