<div dir="ltr">Sorry about that:<div><br></div><div><div>(gdb) info threads</div><div> Id Target Id Frame</div><div> 14 Thread 0x7fcdf5621700 (LWP 32689) "RxPFR1" 0x00007fcdf998589c in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0</div>
<div> 13 Thread 0x7fcdf4e20700 (LWP 32690) "RxPFR2" 0x00007fcdf9241a43 in poll () from /lib/x86_64-linux-gnu/libc.so.6</div><div> 12 Thread 0x7fcdd7fff700 (LWP 32691) "Detect1" 0x00007fcdf9982d84 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0</div>
<div> 11 Thread 0x7fcdd77fe700 (LWP 32692) "Detect2" 0x00007fcdfa692cdf in htp_list_array_get (l=0x7fcdd0c53190, idx=3446) at htp_list.c:98</div><div> 10 Thread 0x7fcdd6ffd700 (LWP 32693) "Detect3" 0x00007fcdf9982d84 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0</div>
<div> 9 Thread 0x7fcdcffff700 (LWP 32694) "Detect4" 0x00007fcdf9982d84 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0</div><div> 8 Thread 0x7fcdd67fc700 (LWP 32695) "Detect5" 0x00007fcdf9982d84 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0</div>
<div> 7 Thread 0x7fcdd5ffb700 (LWP 32696) "Detect6" 0x00007fcdf9982d84 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0</div><div> 6 Thread 0x7fcdd57fa700 (LWP 32697) "Detect7" 0x00007fcdf9982d84 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0</div>
<div> 5 Thread 0x7fcdd4ff9700 (LWP 32698) "Detect8" 0x00007fcdf9982d84 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0</div><div> 4 Thread 0x7fcdcf7fe700 (LWP 32699) "FlowManagerThre" 0x00007fcdf99830fe in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0</div>
<div> 3 Thread 0x7fcdceffd700 (LWP 32700) "SCPerfWakeupThr" 0x00007fcdf99830fe in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0</div><div> 2 Thread 0x7fcdce7fc700 (LWP 32701) "SCPerfMgmtThrea" 0x00007fcdf99830fe in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0</div>
<div>* 1 Thread 0x7fcdfaab2840 (LWP 32668) "Suricata-Main" 0x00007fcdf921908d in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6</div><div>(gdb) t 11</div><div>[Switching to thread 11 (Thread 0x7fcdd77fe700 (LWP 32692))]</div>
<div>#0 0x00007fcdfa692cdf in htp_list_array_get (l=0x7fcdd0c53190, idx=3446) at htp_list.c:98</div><div>98 r = l->elements[i];</div></div><div><div>(gdb) print *l</div><div>$1 = {first = 0, last = 8512, max_size = 16384, current_size = 8512, elements = 0x7fcdd2658c50}</div>
</div><div><br></div><div>Cooper,</div><div> I'll try the dev branch as well.</div><div><br></div><div>Thanks,</div><div>-dave</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 23, 2014 at 9:32 AM, Duarte Silva <span dir="ltr"><<a href="mailto:duarte.silva@serializing.me" target="_blank">duarte.silva@serializing.me</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">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 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>
</div>Hi Dave,<br>
<br>
the print doesn't say much other than the memory address of the variable :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 not,<br>
do this:<br>
<br>
(gdb) print l->max_size<br>
(gdb) print l->current_size<br>
<br>
Cheers,<br>
Duarte<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Also, setting transparent hugepages to always did not seem to prevent this<br>
> from occurring.<br>
><br>
> -dave<br>
><br>
><br>
> On Fri, Jun 20, 2014 at 10:36 PM, Anoop Saldanha <<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 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 destinations<br>
> ><br>
> > and<br>
> ><br>
> > > was able to see the debugging symbols as expected. Attached is a 'perf<br>
> ><br>
> > top'<br>
> ><br>
> > > drilling into the annotated code within htp_list_array_get showing where<br>
> ><br>
> > the<br>
> ><br>
> > > time is being spent (I assume). 9d99, not in the screenshot, shows 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 <<a href="mailto:anoopsaldanha@gmail.com">anoopsaldanha@gmail.com</a><br>
> > ><br>
> > > wrote:<br>
> > >> I don't think --enable-debug compiles it with optimization. Instead<br>
> > >> compile it without optimization, i.e. either -g -O0 or -g -03. Copy<br>
> > >> the new binaries over, like you previously did. You will also have 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 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 the<br>
> > >> threads using "info threads". If you see the offending thread stuck<br>
> > >> in the libhtp get() function call, switch over to that thread using "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 inside<br>
> > >> the libhtp get() function scope that we are trying to trace, you 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 threads<br>
> > >> currently inside htp get() function(gone out of scope at that instance<br>
> > >> of time t), continue the process in gdb, and keep a tab on the 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, 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>
</div></div></blockquote></div><br></div>