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

SEGV due to memory corruption #270

Open
aanon4 opened this issue Sep 28, 2020 · 1 comment
Open

SEGV due to memory corruption #270

aanon4 opened this issue Sep 28, 2020 · 1 comment

Comments

@aanon4
Copy link
Contributor

aanon4 commented Sep 28, 2020

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]

@aanon4
Copy link
Contributor Author

aanon4 commented Oct 1, 2020

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).

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

No branches or pull requests

1 participant