Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory issue during packet release #119

Closed
gkatsikas opened this issue Sep 23, 2018 · 14 comments
Closed

Memory issue during packet release #119

gkatsikas opened this issue Sep 23, 2018 · 14 comments
Assignees
Labels

Comments

@gkatsikas
Copy link
Collaborator

gkatsikas commented Sep 23, 2018

When I replay a trace with raw IP packets I get the following memory dump:

Thread 1 "click" received signal SIGABRT, Aborted.
0x00007ffff5ed0428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
No0 0x00007ffff5ed0428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
No1 0x00007ffff5ed202a in __GI_abort () at abort.c:89
No2 0x00007ffff5f127ea in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7ffff602bed8 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
No3 0x00007ffff5f1b37a in malloc_printerr (ar_ptr=, ptr=, str=0x7ffff6028caf "free(): invalid pointer", action=3) at malloc.c:5006
No4 _int_free (av=, p=, have_lock=0) at malloc.c:3867
No5 0x00007ffff5f1f53c in __GI___libc_free (mem=) at malloc.c:2968
No6 0x000000000066ab2f in Packet::~Packet (this=0x15fbbb0, __in_chrg=) at ../lib/packet.cc:236
No7 WritablePacket::~WritablePacket (this=0x15fbbb0, __in_chrg=) at ../include/click/packet.hh:950
No8 WritablePacket::recycle (p=p@entry=0x15fbbb0) at ../lib/packet.cc:538
No9 0x00000000006019b6 in Packet::kill (this=0x15fbbb0) at ../include/click/packet.hh:1697
No10 EnsureDPDKBuffer::smaction (p=0x15fbbb0, this=0x15ea230) at ../elements/userlevel/ensuredpdkbuffer.cc:87
No11 EnsureDPDKBuffer::simple_action (this=0x15ea230, p=0x15fbbb0) at ../elements/userlevel/ensuredpdkbuffer.cc:106
No12 0x000000000067f9e5 in Element::push (this=0x15ea230, port=0, p=) at ../lib/element.cc:3061
No13 0x00000000006059f8 in Element::Port::push (p=, this=) at ../include/click/element.hh:714
No14 FromDump::run_task (this=0x15e9690) at ../elements/userlevel/fromdump.cc:605
No15 0x00000000006aff29 in Task::fire (this=0x15e9860) at ../include/click/task.hh:584
No16 RouterThread::run_tasks (ntasks=15, this=0x15698f0) at ../lib/routerthread.cc:392
No17 RouterThread::driver (this=0x15698f0) at ../lib/routerthread.cc:613
No18 0x00000000004911ca in main (argc=, argv=) at click.cc:809

To reproduce, use the trace /mnt/traces/caida/caida_939_to_941.pcap on rack7 and a simple configuration:
FromDump -> EnsureDPDKBuffer -> Discard;

@gkatsikas
Copy link
Collaborator Author

I suspect large frames being involved in this memory issue.
I will follow up with more information soon; I just posted the stack trace here for convenience, in order not to forget the issue.

@tbarbette
Copy link
Owner

If extra anno makes the packet bigger than the DPDK buffer size, this may be a problem. But it is still a bug...

@gkatsikas
Copy link
Collaborator Author

Frame with len 2420 bytes causes the crash in this trace.
This confirms our fear about large frames which exceed the DPDK buffer size.

@tbarbette
Copy link
Owner

Do you use your force length option? What is the type of the packet out of FromDump? Still a mmaped buffer, an "expensively pushed" buffer that will have a non-pool buffer?
I think that buffer is released as a pool buffer while it is actually a buffer allocated in place because it is too big to fit in the stand 2K pool.

@gkatsikas
Copy link
Collaborator Author

Interestingly enough, if I don't use FORCE_LEN (i.e., FORCE_LEN=-1), I uncovered another bug.
Because the packets in my raw IP trace do not have MAC header, line 814 in packet.cc causes a crash:

set_mac_header(p->mac_header() ? data() + p->mac_header_offset() : 0);

because p=0

See the stack trace below:

click: ../include/click/packet.hh:2118: void Packet::set_mac_header(const unsigned char*): Assertion `p >= buffer() && p <= end_buffer()' failed.

0 0x00007ffff5ed0428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
1 0x00007ffff5ed202a in __GI_abort () at abort.c:89
2 0x00007ffff5ec8bd7 in _assert_fail_base (fmt=, assertion=assertion@entry=0xb921b8 "p >= buffer() && p <= end_buffer()", file=file@entry=0xb46afd "../include/click/packet.hh", line=line@entry=2118,
function=function@entry=0xbc5720 <ZZN6Packet14set_mac_headerEPKhE19__PRETTY_FUNCTION
> "void Packet::set_mac_header(const unsigned char*)") at assert.c:92
3 0x00007ffff5ec8c82 in _GI___assert_fail (assertion=assertion@entry=0xb921b8 "p >= buffer() && p <= end_buffer()", file=file@entry=0xb46afd "../include/click/packet.hh", line=line@entry=2118,
function=function@entry=0xbc5720 <ZZN6Packet14set_mac_headerEPKhE19__PRETTY_FUNCTION
> "void Packet::set_mac_header(const unsigned char*)") at assert.c:101
4 0x000000000066a84a in Packet::set_mac_header (p=, this=0x15fc100) at ../include/click/packet.hh:2118
5 Packet::copy (this=this@entry=0x15fc100, p=p@entry=0x15fc050, headroom=) at ../lib/packet.cc:814
6 0x0000000000602953 in EnsureDPDKBuffer::smaction (p=0x15fc050, this=0x15eaa80) at ../elements/userlevel/ensuredpdkbuffer.cc:83
7 EnsureDPDKBuffer::simple_action (this=0x15eaa80, p=0x15fc050) at ../elements/userlevel/ensuredpdkbuffer.cc:106
8 0x0000000000680c55 in Element::push (this=0x15eaa80, port=0, p=) at ../lib/element.cc:3061
9 0x0000000000606af8 in Element::Port::push (p=, this=) at ../include/click/element.hh:714
10 FromDump::run_task (this=0x15e9fc0) at ../elements/userlevel/fromdump.cc:610
11 0x00000000006b1199 in Task::fire (this=0x15ea190) at ../include/click/task.hh:584
12 RouterThread::run_tasks (ntasks=127, this=0x156a8f0) at ../lib/routerthread.cc:392
13 RouterThread::driver (this=0x156a8f0) at ../lib/routerthread.cc:613
14 0x000000000049129a in main (argc=, argv=) at click.cc:809

I have a fix for this already

@gkatsikas
Copy link
Collaborator Author

With FORCE_LEN=0 (which crafts the packets with their real length), the trace is injected without errors if I intentionally kill packets longer than 2048 bytes.

gkatsikas added a commit to gkatsikas/fastclick that referenced this issue Sep 24, 2018
This is a temporary solution to the memory issue tbarbette#119

Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>
@tbarbette
Copy link
Owner

Interestingly enough, if I don't use FORCE_LEN (i.e., FORCE_LEN=-1), I uncovered another bug.
Because the packets in my raw IP trace do not have MAC header, line 814 in packet.cc causes a crash:

set_mac_header(p->mac_header() ? data() + p->mac_header_offset() : 0);

This is known and is related to the way click is build, you need a MarkMACHeader after the FromDump. It's the same for IP elements that do not have a CheckIPHeader or MarkIPHeader before them. You need to parse the layer you're working on. I don't think a check should be added in the code. Maybe something static (do I have an element that sets the annotation before me?) but not in the fast path.

@tbarbette
Copy link
Owner

tbarbette commented Sep 24, 2018

max_buffer_length is not really true. Normally when you call make() for a packet too long for the buffer pool, it will do a malloc and will not use the buffer pool. This is not the problem...

@gkatsikas
Copy link
Collaborator Author

Yes, I am digging into it now. The copy operation fails and the packet is getting killed, but it seems that no reference exists. Will be back soon..

tbarbette pushed a commit that referenced this issue Sep 29, 2018
This is a temporary solution to the memory issue #119

Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>
kthkaya added a commit to kthkaya/fastclick that referenced this issue Nov 9, 2018
* proclikefs: remove unused symbol

Moreover it clash with linux/fs.h definition

* ToDevice(.k) : Set queue_mapping to 0

Somehow, even with only one queue in RX this field is dangling.
Fix tbarbette#359. In ixgbe and i40e that lead to accessing an inexisting queue.

Proper support would be to initialize the device with multiple queues,
or us multiple ToDevice with a QUEUE argument and use one queue per
thread. But that's for another day...

* Make KernelTun batch-compatible

* GTPTable : verbose argument

* Make ICMPRewriter batch-compatible

* Fix KernelTun

* GTPLookup: Allow to disable checksum

* LinkUnqueue : allow no bandwidth

* FromDPDKDevice: Allow to change MTU

* Small fixes

* Sync style and few not important things with Metron

* Fix last commit

* Include DPDK in the cc and not the hh

Fix isse with --enable-dpdk-pool because of a dependency loop

* Whoopsie

* Fix error in messages

A bad merge, probably... This will show clearer the problem when there are not enough queues to serve a TX DPDK device. In this case we must rely on locking, but I don't want to start locking automatically. The user may augment the number of available queues with virtual devices.

Should fix tbarbette#71

* Add PRWMP vs RWMP

* Separate LockMP and RWMP

* CounterTest: allow to pass some read

* Add PRWMP vs RWMP

* Separate LockMP and RWMP

* CounterTest: allow to pass some read

* More locks

* Add FORCE_SHRINK parameter to the EnsureHeadroom element

* Inline method in RecordTimestamp's fast path

This patch gives a slight performance boost

Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>

* Allow FromDump to set a fixed frame size

This patch allows FromDump elements to generate packets from
pcap traces while being able to enforce a fixed frame size.
This configuration could be handy when you want to use the very
same Click code to generate either arbitrary frame sizes from a trace
or fixed frame sizes from the same trace.
Default behaviour is unchanged.

Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>

* Do not print delayed packets if requested

User can select to supress warnings about delayed packets.
Default behaviour remains as before

Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>

k

* Fix --enable-dpdk-packet

In theory...

* dpdk: Warn about broken support for mlx5

* Support DPDK 18.05

* Fixed typos in HashTable docs

Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>

* Import changes from Metron regarding DPDK, support up to 18.05

Some changes were made by Georgios Katsikas

Signed-off-by: Tom Barbette <tom.barbette@ulg.ac.be>

* Update README.md

* Link wiki in README.md

* click/etherswitch: Forward traffic to a set of ports

The default behavior of etherswitch is to forward traffic
to all ports except the source when broadcast or to the
destination port found in lookup of etherswitch's mac table.

This commit expands the functionality of etherswitch to
send packet(s) out port(s) iff the port to forward traffic
is enabled. Thus, etherswitch can selectively forward traffic
to particular ports, a feature proving useful with broadcast
traffic so as to avoid traffic loops between click and other
external hardware (e.g. switch).

Ports can selectively be removed and the port forwarding map
can be reset via write handlers "remove_port_forwarding" and
"reset_port_forwarding".

The arguments to "remove_port_forwarding" write handler is a
list of numbers with the first one being a source port and
the others being ports to remove.

For example, "1 2 3 4, 2 3 4" means port 1 will not forward
traffic to ports 2, 3, and 4 -- in addition port 2 will not
forward traffic to ports 3 and 4.

No arguments are necessary for "reset_port_forwarding" write
handler.

Also, the port forwarding map can be viewed via read handler
"port_forwarding".

* Queue do not spawn thread, their puller do

* Configuration for the SuperFluidity testbed

* GTP fixes

* KernelTunMP

Add the KernelTunMP element that support multi-thread read from a TUN/TAP and multi-thread write to a TUN/TAP

Thread safeness for writing is ensure with the usual automatic thread traversal detection of FastClick.
Multi-thread read is done using the THREADS argument. Eg "THREADS 1-3" will use threads 1 to 3 to read packets. Home thread such as set with StaticThreadSched will be ignored !

Seems to work but needs more testing

* Move GTP examples to conf/gtp

* Contribution rules

* Fix categories

* URL update

* Fix warning in timestamp

* Doc for GTP elements

* Fix documentation and style issues

* More warnings...

* Enable batch only if --enable-userlevel is provided

* Fix Kernel compilation up to at least 4.4

And move things around to remove things uncompatible with kernel mode.

Among them batching. But it is not a technical problem, it justs needs a
little refactoring to work in kernel.

Anyway, as mainline Click, the kernel mode is not working very well with
recent versions, that should be fixed before batching.

There may be some unfixed platform dependencies such as ARM, don't
hesitate to fix them too.

* Fix userlevel

I moved some things a little too fast...

* Fix test dependencies too

* Fix the research package

* Preliminary support for DPDK 18.08

This patch is based on DPDK 18.08-rc1

Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>

* Added MLX5 dependency on libmnl

This patch adds support for 18.08-rc2.
Also, rebased the branch based on latest master changes

Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>

* Fix DPDK 18.08

- Mask RSS flags that are not supported
- Use hardware default ring size if provided, or DPDKDevice's default
if not

* Fix compilation with older DPDK versions

* Update README.md

* Fix compilation with DPDK 18.02

That option was added in 18.05

* Reduce the amount of Travis tests

Let's test all DPDK version with batching, but only a few without batching as those features do not influence each other much.

* Travis: Compile with machine=default

Some travis machines are older, and do not support some instruction set

* DPDK: Allow to set PAUSE mode

Argument is either NONE, RX, TX or FULL

* DPDK: Types and warning fixes

* Remove unused variable

* Avoid clang override warning as of now

Waayyy to many to fix

* TimestampDiff : Allow to print delay since a certain index

* RecordTimestamp : Add the avg alias

* RecordTimestamp: Fix testie

On travis, the latency can be very long

* TimestampDiff bugfix

To compute the average, the sum must be divided by the total - index

* click: Add --simtick options

Allows to change the amount of tick to warp in simtime mode

This allows to force us scale to enable some testing

* IPRewriterMap : Very small doc fix

* dpdk: Compiling with the default is not an export

In the hope to fix travis (finally ?)

* Travis: Last supported is 18.08, let's use it

* Timewarp test: relax constraint and more robust

The timewrap test fails from time to time on travis, which is very slow.
The time to launch the process makes the delay longer than expected, so
let's relax the constraints.

In addition, substract from the real time the time it takes to launch an
empty click. This allows to be less error-proned regarding the time
a process takes to execute, eg on travis.

* Typo

* Allow to list pools in handlers

* Fix building with shared libs

* Pipeliner: Fix message

Without consequence, but it did not display information for some threads

* Batching helpers

Actually vanilla helpers too...

* PaintRR element

See hh for description. It is also the first example of ClassifyElement.

* Update PR per Georgios Katsikas comments

* dpdk: Allow to read rx_nombufs stat

* Style fixes in fromdpdkdevice.cc

Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>

* TimestampDiff: do not compute unneded informations

* Make Pad element batch-compatible

Also fix the SimpleElement helper

* Remove some warnings

Various styling, unused stuffs, integer comparison, ...

* Repair click-devirtualize and click-makepackage

Should fix issue tbarbette#37.

Regarding DPDK :
 - Export needed includes to the tools

Regarding makepackage :
 - smaction is reserved as a inline Packet*. Without nowing that we
 did some "inline void" smaction, for read-only smaction. So I renamed
 all of those smaction as rmaction (for read simple action).

Regarding click-devirtualize:
 - Added support for push_batch

* Reorganise conf folder

Finally clean all that shit per main topics of interest.

The README provides some generic explanations.

If people read this, it would be great to add :

- L2 switch example
- More self-contained "tutorial" examples. Probably userlevel with
  KernelTAP that works nearly always and allow the user to play.

* Add tutorial examples

* Reference wiki and push to the wiki dev info

* Commiy changes generated from the configure.in

* Fix DPDK 17.11

* Fix last commit for DPDK > 17.11 with Octeon

* If using DPDK, allocate memory from DPDK mem

Allows to simply use huge pages and cache alignment (mem is allocated on
boundary, and headroom is changed to be a multiple of cacheline size)

* Batching support for VLAN elements

Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>

* Batching support for EnsureEther

Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>

* EtherEncap batching helper

Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>

* ReplayUnqueue : Allow to replay according to ts

If the TIMING parameter is > 0, ReplayUnqueue will replay
according to the packet timestamp. TIMING is an integer and if
bigger than 1 will define the acceleration speed. A value of 2
will replay packets twice faster, ...

* Fix first packet never being sent

Timestamp of diff packets must start with 0, so first packet is always
sent and then the difference is computed from that packet

* Replay: Make the timing difference over the whole replay

Problem is that it was not able to replay at 100G because Click would
spend all its time in the clock function.

Using the diff over the whole replay time is also much more precise than
waiting for the interframe

* Reset time when restarting from active handler

* RecordTimestamp: Differentiate double read from uninitialized

* dpdk: Allow to set number of mbufs per pool

* Replay: No need for inlining here

* Support for any percentiles

* TIMING is only supported by ReplayUnqueue

* Small fixes as per Georgios Katsikas comments

Also, return 0 if someone asks for the latency of the current index

* Use Click parser and fix test

The replay start at the time of the first packet now, always

* click/lexer: fix double free when aliasess are created for elementclasses

In the Lexer, when an elementclass is encountered, the parser saves state
and begins parsing the inner configuration.  The ParserState is pushed onto
a stack and a Compound is attached as a thunk.  When you exit the
elementclass, the ParserState is popped and the Compound is destroyed.

However, when an elementclass is aliased, a synonym references the Compound
by pointer.  When the synonym is destroyed, it also deletes the thunk; this
causes a double free EVERY time the Lexer encounters an aliased
elementclass.

In kclick, this manifests as a corrupted SLUB freelist, which often results
in a memory leak, an infinite loop in kmalloc, or a panic.

This change adds a refcount to Compound and performs get/put operations,
deleting it when there are zero refs.  Prior to this change, AFL was able to
generate a config that would double free in remove_element_type.  The config
no longer double frees after this change.  I used valgrind to verify that no
memory leaks were caused as a result of refcounting.

Originally I modified add_element_type to get a ref; however, only one call
site actually needs to do this, so code to put the extra ref needed to be
added after all the other call sites.  Therefore, I just added the get
before that specific call site.

I did not add refs when Compounds are chained & it doesn't seem to affect
this particular test.

Thanks, American Fuzzy Lop

Change-Id: Idf20188d14f392aa5ab5f4bd1ad48763eb3a7929

* FromDump reworked

This enhances the way parameter FORCE_LEN works.
When FORCE_LEN==-1, FromDump works as before.
When FORCE_LEN=x, where x in [MIN_MTU, MAX_MTU], each
frame is crafted with a fixed length x bytes.
When FORCE_LEN=0, each frame takes its original (actual)
length.
IP checksums are properly computed when needed.

Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>

* Clean-up comments in FromDump

Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>

* Keep useful comment

Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>

* FromDump excludes packets that exceed the max buffer len

This is a temporary solution to the memory issue tbarbette#119

Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>

* FromDump can only enlarge frames up to 2048 bytes

This is a temporary solution to the problem so let's keep
this pull request open until I commit a better solution
to the memory problem

Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>

* Kill packets upon failure

This commit closes the pull request on my side.
Now the focus shifts to the memory management issue once
FromDump has allocated a large enough packet outside of
the DPDK zone.

Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>

* lexer: fix Compound::expand_into sanity check

The check here appears to be intended to make sure that we only connect if
both indexes are valid; specifically, idx can be -1.  Unfortunately, it
checks (*cp)[0] twice.  Instead, check (*cp)[1] too.

Thanks, American Fuzzy Lop

Change-Id: I5cdeb45ac0cef5bbb0a18c6f19b4540df8007bfe

* ip6address: fix parser array bounds issue/crash

A malformed IP6Address, i.e. with more than 8 components, will cause the
memmove/memset at the end of parsing to fail.  This code is supposed to move
the post-:: bytes to the end of the address and zero out the bytes in the
center.  Instead, it moves some of the bytes the wrong way, potentially
writing prior to parts[] and then zeroing with a negative size.

Instead, make the parser stop when it hits 8 components and let parse figure
out that we did not consume the entire String.

Thanks: American Fuzzy Lop

Change-Id: I2966cb22fb5b44eb9e92dfc6a94e891cf5d02fa7

* Library: Add a library folder in conf

Let's have a few elementclass that implements what everyone repeats

* Fix documentation

* Add link to code in documentation, and support for batching

* Ignore vim history

* From*Device: Add SCALE parameter

If parallel, all available threads will open one queue of each device,
for better load balancing.
If shared (current default and behaviour), threads will be split among
devices, for better CPU locality.

* ToDPDKDevice: Fix bug introduced by last commit

* SetIPAddress: Make batch-compatible

* Move gtp package to tunnel

Soon to add GRE and ERSPAN, let's not make thousands packages, those are
all for some kind of encapsulation

* Support ERSPAN decapsulation

Allows to set various informations in annotations, timestamp if Type 3,
...

* If egress/ingress not available, use encap as paint

* FromDPDKDevice: Allow to read MTU using handlers

* Travis : enable tunneling

* DPDK: Accept on and off (like ethtool) for pause frame parameters

* String: import from metron

Add the split function
Correction in trim, by Georgios Katsikas

* CPUSwitch : import from Metron

Correct the get_spawning_threads function

CPUSwitch outputs packets oon a given output with only one CPU, of course

* Fix warnings

* Prepare for DPDK 18.11

* DPDK: Import h_queue_count from Metron

The handler allows to query the number of packets left in the queue

* DPDK: Fix queue assignation (import from Metron)

Some odd assignment could create a problem there

* Import from Metron: configure detection

* IPReassembler: pack ChunkLink, since it can be arbitrarily placed in Packet::data

These two uint16_ts may end up placed at arbitrary offsets into a packet.
In order to generate proper unaligned read/write instructions, mark the
struct as packed.

This was exposed by Defensic suite IPv4 Header Fragment-offset, test 45067
and discovered by Waldin Stone.  I verified it by asserting proper alignment
of ChunkLinks and found that they were not always properly aligned.

* ip/ipreassembler: account for header length changes

When storing the first of a series of fragments, IPReassembler copies the IP
header from the fragment to the reassembly buffer.  However, the header of
the new fragment may not be the same length as the original fragment that
created the buffer.  If the new fragment's header is shorter, we will end up
with weirdness preceeding the payload.  If the new fragment's header is
longer, we will overwrite the payload and possibly overrun it.  Both cases
show up as 'bad mem_used' warnings.

Changing header_delta in the p_off=0 case to account for header length
changes (and not just offset changes) fixes the issue.

Found by Waldin Stone, running Defensics.
Signed-off-by: pallas@meraki.com

* ip/ipreassembler: make sure to expand packet enough to hold ChunkLink

We actually need to make sure to expand the data area to hold ChunkLink;
right now, it's just checking the size of the data, so we might write out of
bounds later on.

Found-by: jtruba@meraki.com
Thanks: AddressSanitizer

* Configurable headroom for RatedSource

Also description update for InfiniteSource
@tbarbette
Copy link
Owner

WHere are we on this?

@gkatsikas
Copy link
Collaborator Author

no progress on this, will be back after the submission..

@pallas
Copy link
Collaborator

pallas commented Nov 14, 2018

WritablePacket::make might not succeed. There needs to be a bailout prior to q->copy.

@gkatsikas
Copy link
Collaborator Author

Indeed, this check is mandatory both in EnsureDPDKBuffer and EnsureNetmapBuffer smactions.
However, the problem in my case does not occur due to null pointer q returned by make().
The failure occurs in q->copy(), which in turn results in p->kill() (in the else branch).
This kill is performed on the wrong object in my opinion (q->kill() should have been called).

@tbarbette tbarbette assigned tbarbette and gkatsikas and unassigned tbarbette Dec 3, 2018
@gkatsikas gkatsikas added wait-for-op Additional information from the OP are needed bug and removed wait-for-op Additional information from the OP are needed labels Dec 3, 2018
@gkatsikas
Copy link
Collaborator Author

See a fix proposed in PR #161

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants