[Bro-Dev] help Reading the backtrace

[Aashish Sharma]

SO this doesn't (at the moment) seem to be related to table expiration. My table is maintained on manager and expire_func only runs on manager.  

But, I see 'a' worker stall with 99-100% CPU for a good while while all other workers go down to 5-6% CPU. conn.log continues to grow though

GDB points to : Get() in install/bro-2.5/src/threading/Queue.h : 

template<typename T>
inline T Queue<T>::Get()
        {
        safe_lock(&mutex[read_ptr]);

        int old_read_ptr = read_ptr;

        if ( messages[read_ptr].empty() && ! ((reader && reader->Killed()) || (writer && writer->Killed())) )
                {
                struct timespec ts;
                ts.tv_sec = time(0) + 5;
                ts.tv_nsec = 0;

----->          pthread_cond_timedwait(&has_data[read_ptr], &mutex[read_ptr], &ts);


On a side note, Well, why is this on bro-dev ? Not entirely sure. :) I think eventually this might go into what my script is messing up and whats a better way to script the code, I suppose. 

Aashish 


On Thu, Jan 19, 2017 at 09:55:40AM -0800, Robin Sommer wrote:
> 
> 
> On Thu, Jan 19, 2017 at 09:44 -0800, you wrote:
> 
> > Still, to clearify, there might be a possibility that because at
> > present table_incremental_step=5000, somehow expiring >> 5000 entries
> > continiously every moment might cause cause Queue to deadlock
> > resulting in BRO to stop packets processing ?
> 
> It shouldn't deadlock. What I can see happening, depending on load and
> these parameters, is Bro spending most of its time going through the
> table to expire entries and only getting to few packets in between (so
> not complete stop of processing, but not getting much done either)
> 
> Robin
> 
> -- 
> Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin