<p dir="ltr">Anything I should do to tune the list size downward? If so, what implications does that have for inspection? Thanks! </p>
<p dir="ltr">-dave</p>
<div class="gmail_quote">On Jun 23, 2014 10:56 AM, "Anoop Saldanha" <<a href="mailto:anoopsaldanha@gmail.com">anoopsaldanha@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dave,<br>
<br>
That's a huge list and that's pretty much the issue without doubt.<br>
<br>
On Mon, Jun 23, 2014 at 8:21 PM, David Vasil <<a href="mailto:davidvasil@gmail.com">davidvasil@gmail.com</a>> wrote:<br>
> Sorry about that:<br>
><br>
> (gdb) info threads<br>
>   Id   Target Id         Frame<br>
>   14   Thread 0x7fcdf5621700 (LWP 32689) "RxPFR1" 0x00007fcdf998589c in<br>
> __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0<br>
>   13   Thread 0x7fcdf4e20700 (LWP 32690) "RxPFR2" 0x00007fcdf9241a43 in poll<br>
> () from /lib/x86_64-linux-gnu/libc.so.6<br>
>   12   Thread 0x7fcdd7fff700 (LWP 32691) "Detect1" 0x00007fcdf9982d84 in<br>
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0<br>
>   11   Thread 0x7fcdd77fe700 (LWP 32692) "Detect2" 0x00007fcdfa692cdf in<br>
> htp_list_array_get (l=0x7fcdd0c53190, idx=3446) at htp_list.c:98<br>
>   10   Thread 0x7fcdd6ffd700 (LWP 32693) "Detect3" 0x00007fcdf9982d84 in<br>
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0<br>
>   9    Thread 0x7fcdcffff700 (LWP 32694) "Detect4" 0x00007fcdf9982d84 in<br>
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0<br>
>   8    Thread 0x7fcdd67fc700 (LWP 32695) "Detect5" 0x00007fcdf9982d84 in<br>
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0<br>
>   7    Thread 0x7fcdd5ffb700 (LWP 32696) "Detect6" 0x00007fcdf9982d84 in<br>
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0<br>
>   6    Thread 0x7fcdd57fa700 (LWP 32697) "Detect7" 0x00007fcdf9982d84 in<br>
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0<br>
>   5    Thread 0x7fcdd4ff9700 (LWP 32698) "Detect8" 0x00007fcdf9982d84 in<br>
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0<br>
>   4    Thread 0x7fcdcf7fe700 (LWP 32699) "FlowManagerThre"<br>
> 0x00007fcdf99830fe in pthread_cond_timedwait@@GLIBC_2.3.2 () from<br>
> /lib/x86_64-linux-gnu/libpthread.so.0<br>
>   3    Thread 0x7fcdceffd700 (LWP 32700) "SCPerfWakeupThr"<br>
> 0x00007fcdf99830fe in pthread_cond_timedwait@@GLIBC_2.3.2 () from<br>
> /lib/x86_64-linux-gnu/libpthread.so.0<br>
>   2    Thread 0x7fcdce7fc700 (LWP 32701) "SCPerfMgmtThrea"<br>
> 0x00007fcdf99830fe in pthread_cond_timedwait@@GLIBC_2.3.2 () from<br>
> /lib/x86_64-linux-gnu/libpthread.so.0<br>
> * 1    Thread 0x7fcdfaab2840 (LWP 32668) "Suricata-Main" 0x00007fcdf921908d<br>
> in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6<br>
> (gdb) t 11<br>
> [Switching to thread 11 (Thread 0x7fcdd77fe700 (LWP 32692))]<br>
> #0  0x00007fcdfa692cdf in htp_list_array_get (l=0x7fcdd0c53190, idx=3446) at<br>
> htp_list.c:98<br>
> 98              r = l->elements[i];<br>
> (gdb) print *l<br>
> $1 = {first = 0, last = 8512, max_size = 16384, current_size = 8512,<br>
> elements = 0x7fcdd2658c50}<br>
><br>
> Cooper,<br>
>   I'll try the dev branch as well.<br>
><br>
> Thanks,<br>
> -dave<br>
><br>
><br>
> On Mon, Jun 23, 2014 at 9:32 AM, Duarte Silva <<a href="mailto:duarte.silva@serializing.me">duarte.silva@serializing.me</a>><br>
> wrote:<br>
>><br>
>> On Monday 23 June 2014 09:08:45 David Vasil wrote:<br>
>> > Here is the result after removing all of the -O2's from the libhtp<br>
>> > makefile<br>
>> > and waiting for a detect thread to hit 100%.<br>
>> ><br>
>> > <a href="http://pastebin.com/aHp415HV" target="_blank">http://pastebin.com/aHp415HV</a><br>
>><br>
>> Hi Dave,<br>
>><br>
>> the print doesn't say much other than the memory address of the variable<br>
>> :P<br>
>> Instead, could you do a:<br>
>><br>
>> (gdb) print *l<br>
>><br>
>> It should print all of the members of the htp_list_array_t structure. If<br>
>> not,<br>
>> do this:<br>
>><br>
>> (gdb) print l->max_size<br>
>> (gdb) print l->current_size<br>
>><br>
>> Cheers,<br>
>> Duarte<br>
>><br>
>> ><br>
>> > Also, setting transparent hugepages to always did not seem to prevent<br>
>> > this<br>
>> > from occurring.<br>
>> ><br>
>> > -dave<br>
>> ><br>
>> ><br>
>> > On Fri, Jun 20, 2014 at 10:36 PM, Anoop Saldanha<br>
>> > <<a href="mailto:anoopsaldanha@gmail.com">anoopsaldanha@gmail.com</a>><br>
>> ><br>
>> > wrote:<br>
>> > > Dave,<br>
>> > ><br>
>> > > Nice!  You did manage to catch that thread inside the get() function.<br>
>> > > From the perf-top it indicates that it's the same issue, although it<br>
>> > > would be nice if I could look at the contents of the variable "l"<br>
>> > > inside that get() function.  Unfortunately from your gdb output it<br>
>> > > looks like you forgot to compile libhtp without(i typed it wrongly as<br>
>> > > "with" in my previous mail, instead of "without", although I did<br>
>> > > specify -g3 later on) optimization.<br>
>> > ><br>
>> > > Can you get the output of "print l" inside the get() function, but<br>
>> > > without optimization enabled in the libhtp library.<br>
>> > ><br>
>> > > You will have to rebuild libhtp without optimization.  Go to your<br>
>> > > libhtp build directory.  Run the "configure" command like you have<br>
>> > > before.  Before you type "make", search for "Makefile" in the libhtp<br>
>> > > root/base directory and the "htp" subdirectory, and replace "-g -O2"<br>
>> > > with just "-g".  Now run the make command.  Confirm during the build<br>
>> > > stage on the console that you don't have "-g -o2" with any of the gcc<br>
>> > > commands and instead have just "-g".<br>
>> > ><br>
>> > > You can then do a "make install", OR manually copy the .so files<br>
>> > > directory from "htp/.libs/" directory, to replace the libhtp libraries<br>
>> > > that you are linking with suricata.<br>
>> > ><br>
>> > > If you still can't see the symbols inside libhtp's functions when you<br>
>> > > run suricata, your suricata binary is pointing to the wrong/old libhtp<br>
>> > > library.<br>
>> > ><br>
>> > ><br>
>> > > On Sat, Jun 21, 2014 at 12:42 AM, David Vasil <<a href="mailto:davidvasil@gmail.com">davidvasil@gmail.com</a>><br>
>> > ><br>
>> > > wrote:<br>
>> > > > I was able to do this after Detect5 hit 100% and stayed there.  I<br>
>> > ><br>
>> > > reverted<br>
>> > ><br>
>> > > > back to my originally compiled suricata 2.0.1 deb package (without<br>
>> > > > --enable-debug) as that flag created a ton of overhead - as you<br>
>> > ><br>
>> > > mentioned,<br>
>> > ><br>
>> > > > probably due to not being compiled with optimization - and it also<br>
>> > > > ended<br>
>> > ><br>
>> > > up<br>
>> > ><br>
>> > > > core dumping several times.  I copied the unstripped libhtp lib and<br>
>> > ><br>
>> > > suricata<br>
>> > ><br>
>> > > > binary (again, without --enable-debug) to the appropriate<br>
>> > > > destinations<br>
>> > ><br>
>> > > and<br>
>> > ><br>
>> > > > was able to see the debugging symbols as expected.  Attached is a<br>
>> > > > 'perf<br>
>> > ><br>
>> > > top'<br>
>> > ><br>
>> > > > drilling into the annotated code within htp_list_array_get showing<br>
>> > > > where<br>
>> > ><br>
>> > > the<br>
>> > ><br>
>> > > > time is being spent (I assume).  9d99, not in the screenshot, shows<br>
>> > > > the<br>
>> > > ><br>
>> > > > following:<br>
>> > > >     0.08 :            9d99:       repz retq<br>
>> > > ><br>
>> > > >          :            free(l->elements);<br>
>> > > >          :            free(l);<br>
>> > > >          :<br>
>> > > >          :        }<br>
>> > > ><br>
>> > > > GDB from this is thread here: <a href="http://pastebin.com/3tfjTsL0" target="_blank">http://pastebin.com/3tfjTsL0</a><br>
>> > > ><br>
>> > > > Thanks!<br>
>> > > > -dave<br>
>> > > ><br>
>> > > ><br>
>> > > > On Fri, Jun 20, 2014 at 9:41 AM, Anoop Saldanha<br>
>> > > > <<a href="mailto:anoopsaldanha@gmail.com">anoopsaldanha@gmail.com</a><br>
>> > > ><br>
>> > > > wrote:<br>
>> > > >> I don't think --enable-debug compiles it with optimization.<br>
>> > > >> Instead<br>
>> > > >> compile it without optimization, i.e. either -g -O0 or -g -03.<br>
>> > > >> Copy<br>
>> > > >> the new binaries over, like you previously did.  You will also have<br>
>> > > >> to<br>
>> > > >> compile libhtp the same way.  You can either specify this in the<br>
>> > > >> environment variable with configure or manually edit the configure<br>
>> > > >> script and the makefiles, replacing all "-g -o2" with just "-g".<br>
>> > > >><br>
>> > > >> 1. You can start suricata, and wait for one of the detect threads<br>
>> > > >> to<br>
>> > > >> hit the 100% cpu utilization mark(make a note of the detect<br>
>> > > >> threadname).<br>
>> > > >> 2. One you see that, attach gdb to the running process, and print<br>
>> > > >> the<br>
>> > > >> threads using "info threads".  If you see the offending thread<br>
>> > > >> stuck<br>
>> > > >> in the libhtp get() function call, switch over to that thread using<br>
>> > > >> "t<br>
>> > > >> <thread_number>" and do a "print l".  The symbol "l" is inside the<br>
>> > > >> libhtp get() function call.  Unless you have the detect thread<br>
>> > > >> inside<br>
>> > > >> the libhtp get() function scope that we are trying to trace, you<br>
>> > > >> won't<br>
>> > > >> have the symbol available for printing.<br>
>> > > >> 3. If when you do a "info threads", you don't see any of the<br>
>> > > >> threads<br>
>> > > >> currently inside htp get() function(gone out of scope at that<br>
>> > > >> instance<br>
>> > > >> of time t), continue the process in gdb, and keep a tab on the<br>
>> > > >> threads<br>
>> > > >> with top/htop, till you see the detect thread(s) again hit the 100%<br>
>> > > >> cpu mark, post which you can interrupt the process inside gdb again<br>
>> > > >> and hopefully find the detect thread still inside the libhtp get()<br>
>> > > >> function context.<br>
>> > > >><br>
>> > > >> With the issue at hand, once the thread gets pegged, you should be<br>
>> > > >> able to zero-in on the thread pretty quickly.  In case you can't,<br>
>> > > >> I'll<br>
>> > > >> provide a debug patch to corner the issue.<br>
>> > ><br>
>> > > --<br>
>> > > -------------------------------<br>
>> > > Anoop Saldanha<br>
>> > > <a href="http://www.poona.me" target="_blank">http://www.poona.me</a><br>
>> > > -------------------------------<br>
>><br>
><br>
<br>
<br>
<br>
--<br>
-------------------------------<br>
Anoop Saldanha<br>
<a href="http://www.poona.me" target="_blank">http://www.poona.me</a><br>
-------------------------------<br>
</blockquote></div>