Closed GoogleCodeExporter closed 9 years ago
Hey, Lukas,
Thanks for the patch! I'll work on integrating this during the next day or
two, and send you an update as things progress.
Would you like your name added to the AUTHORS file? If so, just let me know
the email address to use, etc.
--Graeme
Original comment by gconnell@google.com
on 28 Jul 2014 at 5:26
It's "Lukas Lueg <lukas.lueg@gmail.com>"
I have no knowledge when pcap_offline_filter() was added to pcap or if it is
available on all platforms; the function may have to get stubbed.
Original comment by lukas.l...@gmail.com
on 30 Jul 2014 at 6:49
Hey, Lukas,
Just wanted to give you a quick update on this. Work is in progress, I'm just
doing a few tweaks to the API, and I should have something out early next week,
Monday at the best.
Thanks again!
Original comment by gconnell@google.com
on 1 Aug 2014 at 11:21
This is out, as of
https://code.google.com/p/gopacket/source/detail?r=e6b5b3373263a6d3e18506c02e984
940337b4ddf
Original comment by gconnell@google.com
on 7 Aug 2014 at 2:46
Ok, thanks.
Be aware that there is a subtle change in the API which also now mismatches the
docs: NewBPF() originally put the finalizer on the hidden field BPF.bpf instead
of BPF{} itself; the point about not putting the finalizer on the struct (as
loosely documented) is that some code outside of gopacket may put a finalizer
on struct itself, causing a memory leak as C.pcap_freecode() is never called.
Original comment by lukas.l...@gmail.com
on 7 Aug 2014 at 3:00
Ah, interesting. I actually put it on the &BPF{} instead of bpf.bpf because of
this section of http://golang.org/pkg/runtime/#SetFinalizer :
"The argument x must be a pointer to an object allocated by calling new or by
taking the address of a composite literal."
Since bpf.bpf does not technically fit that description, I felt it safer to use
&BPF{} itself, which does. Things work with the bpf.bpf way currently, but I
worry that some future GC change might cause a breakage.
Original comment by gconnell@google.com
on 7 Aug 2014 at 3:04
I stumbled upon the same section, which gives a second requirement about the
func-parameter and ends in " If either of these is not true, SetFinalizer
aborts the program".
What I take away from this is that SetFinalizer does check if the pointer is
actually maintained by the gc. Otherwise it would not be able to check the
stated condition and "abort the program".
Original comment by lukas.l...@gmail.com
on 7 Aug 2014 at 3:14
Original issue reported on code.google.com by
lukas.l...@gmail.com
on 26 Jul 2014 at 9:01Attachments: