[Bro] pcap_next Question

[Chris Crawford]

I've been doing some thinking about this thread lately.

Here's the bit of code related to the last post in this thread
(http://mailman.icsi.berkeley.edu/pipermail/bro/2012-May/005564.html)

Reassem.cc, starting at line 23:


       block = new u_char[size];
       if ( ! block )
                reporter->InternalError("out of memory");


Since the new operator is throwing a std::bad_alloc error, that line
should be surrounded with a bit of error handling like in the attached
patch file. (To apply, copy to bro/src and use "patch
--ignore-whitespace < Reassem.cc.patch").

The result would look something like this:

       try
       {
               block = new u_char[size];
       }
       catch(std::bad_alloc& exc)
       {
                reporter->InternalError("out of memory");
       }


That way, if there is no memory available, at least this error can be
handled gracefully.

As it is right now, if new fails to allocate memory, the following if
statement will never execute and the end user will never see the "out
of memory" message in their logs.

-Chris

On Mon, May 21, 2012 at 3:45 PM, Siwek, Jonathan Luke
<jsiwek at illinois.edu> wrote:
>
>> So, either
>> pcap_next is returning an out of bounds pointer, or something happens
>> to data between the point in time when pcap_next returns a values and
>> PktSrc::Process calls net_packet_dispatch.
>
> Could be, but then I'd expect a segfault much earlier, at least before NetSessions::DoNextPacket() when the packet data is accessed.  In the end, your crash doesn't look related to accessing that data at all, it's an unhandled exception thrown from operator new[] (failure to allocate memory).
>
> Another possibility could be that since GDB is working with optimized code (the reason why some arguments are "<value optimized out>"), the "out of bounds" indicators don't necessarily indicate a problem yet.  If you `./configure --enable-debug` then rebuild/reinstall to disable optimizations, you can see if stack traces for future crashes start reporting valid addresses for the pointer.
>
> +Jon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Reassem.cc.patch
Type: application/octet-stream
Size: 501 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20120808/b4c53cb0/attachment.obj