You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I really wish I could give you more, but the stack traces I get on crash mostly indicate some form of memory corruption rather than an easily reproduced issue (sorry). I have an app which creates and destroys pcap instances many times. The release of the pcap object (after it's been closed) will cause my application to SEGV at some point afterward. Sometimes, but no always, this is while the Node GC is running. The only thing I've been able to do to stop the crashes is to hang on to a reference to the binding.PcapSession internal object after I close and remove other references (this is perhaps not a surprise). Obviously having lots of those hanging about is undesirable.
Mostly filing this issue in case others are seeing this and we might compare notes.
Update: While not a fix as such, I'm now using a fork of this code which reuses the native pcap objects and this seems to work great. Worst case is I have N of these hanging around (where N is the number of captures I'm running in parallel).
I really wish I could give you more, but the stack traces I get on crash mostly indicate some form of memory corruption rather than an easily reproduced issue (sorry). I have an app which creates and destroys pcap instances many times. The release of the pcap object (after it's been closed) will cause my application to SEGV at some point afterward. Sometimes, but no always, this is while the Node GC is running. The only thing I've been able to do to stop the crashes is to hang on to a reference to the binding.PcapSession internal object after I close and remove other references (this is perhaps not a surprise). Obviously having lots of those hanging about is undesirable.
Mostly filing this issue in case others are seeing this and we might compare notes.
Here's a typical crash trace:
*** Error in `node': double free or corruption (out): 0x00000000039bd960 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x70bfb)[0x7fd347972bfb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76fc6)[0x7fd347978fc6]
/lib/x86_64-linux-gnu/libc.so.6(+0x7780e)[0x7fd34797980e]
node(_ZN2v88internal4Heap8ScavengeEv+0x1e3a)[0xf43dba]
node(_ZN2v88internal4Heap24PerformGarbageCollectionENS0_16GarbageCollectorENS_15GCCallbackFlagsE+0x3e4)[0xf49314]
node(_ZN2v88internal4Heap14CollectGarbageENS0_15AllocationSpaceENS0_23GarbageCollectionReasonENS_15GCCallbackFlagsE+0x3ab)[0xf4a18b]
node(_ZN2v88internal4Heap26AllocateRawWithRetryOrFailEiNS0_15AllocationSpaceENS0_19AllocationAlignmentE+0x41)[0xf4cec1]
node(_ZN2v88internal7Factory30CopyJSObjectWithAllocationSiteENS0_6HandleINS0_8JSObjectEEENS2_INS0_14AllocationSiteEEE+0x95)[0xf29875]
node[0x11d89c4]
node[0x11de450]
node(_ZN2v88internal27Runtime_CreateObjectLiteralEiPPNS0_6ObjectEPNS0_7IsolateE+0xbe)[0x11e045e]
[0x3417226cfc5d]
The text was updated successfully, but these errors were encountered: