<div dir="ltr">I was able to do this after Detect5 hit 100% and stayed there.  I reverted back to my originally compiled suricata 2.0.1 deb package (without --enable-debug) as that flag created a ton of overhead - as you mentioned, probably due to not being compiled with optimization - and it also ended up core dumping several times.  I copied the unstripped libhtp lib and suricata binary (again, without --enable-debug) to the appropriate destinations and was able to see the debugging symbols as expected.  Attached is a 'perf top' drilling into the annotated code within htp_list_array_get showing where the time is being spent (I assume).  9d99, not in the screenshot, shows the following:<div>
<br></div><div><div>    0.08 :            9d99:       repz retq </div><div>         :            free(l->elements);                 </div><div>         :            free(l);    </div><div>         :        } </div><div class="gmail_extra">
<br></div><div class="gmail_extra">GDB from this is thread here: <a href="http://pastebin.com/3tfjTsL0">http://pastebin.com/3tfjTsL0</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks!</div><div class="gmail_extra">
-dave<br><br><div class="gmail_quote">On Fri, Jun 20, 2014 at 9:41 AM, Anoop Saldanha <span dir="ltr"><<a href="mailto:anoopsaldanha@gmail.com" target="_blank">anoopsaldanha@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.</blockquote></div></div></div></div>