[Bro] pcap_next Question

[Chris Crawford]

Looks like the patch file did not post to the list.

This is what it looks like:


--- Reassem.cc  2012-01-11 16:53:40.000000000 -0500
+++ Reassem.cc.new      2012-08-06 22:32:52.000000000 -0400
@@ -20,9 +20,14 @@
        seq = arg_seq;
        upper = seq + size;

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

        memcpy((void*) block, (const void*) data, size);

-Chris

On Wed, Aug 8, 2012 at 11:20 AM, Chris Crawford
<christopher.p.crawford at gmail.com> wrote:
> 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