Memory Leak

I’ve been using noble and bleacon for a while, for recording data from a few hundred BLE beacons broadcasting fairly frequently and have run into a memory leak with running simple tasks.

const noble = require('noble')

noble.on('stateChange', function (state) {
	if (state == "poweredOn") {
		noble.startScanning()
	}
})


noble.on('discover', function (perip) {
	console.log(perip.id)
})

And after half a day of running i get the following crash.

<--- Last few GCs --->
[2535:0x31dd550] 40825511 ms: Mark-sweep 1327.0 (1350.3) -> 1326.9 (1350.3) MB, 2171.0 / 0.0 ms  allocation failure GC in old space requested
[2535:0x31dd550] 40827774 ms: Mark-sweep 1326.9 (1350.3) -> 1326.9 (1348.8) MB, 2262.2 / 0.0 ms  last resort 
[2535:0x31dd550] 40830039 ms: Mark-sweep 1326.9 (1348.8) -> 1326.9 (1348.8) MB, 2265.5 / 0.0 ms  last resort 
<--- JS stacktrace --->

==== JS stack trace =========================================
Security context: 0xa2cb70a66a1 <JS Object>
    1: onDiscover [/home/avatar7/beacon_listener/node_modules/noble/lib/noble.js:~109] [pc=0x12f4b33a57bc](this=0x2b54c19c5ec9 <a Noble with map 0x390337a29299>,uuid=0x2d80e2fbf7f9 <String[12]: f074d2f5287e>,address=0x2d80e2fbf889 <String[17]: f0:74:d2:f5:28:7e>,addressType=0x1636abc12c29 <String[6]: random>,connectable=0x1636abc02421 <false>,advertisement=0x2d80e2fbf841 <an Object...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [node]
 2: 0x134e91c [node]
 3: v8::Utils::ReportOOMFailure(char const*, bool) [node]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [node]
 5: v8::internal::Factory::NewFixedArray(int, v8::internal::PretenureFlag) [node]
 6: v8::internal::HashTable<v8::internal::NameDictionary, v8::internal::NameDictionaryShape, v8::internal::Handle<v8::internal::Name> >::New(v8::internal::Isolate*, int, v8::internal::MinimumCapacity, v8::internal::PretenureFlag) [node]
 7: v8::internal::Dictionary<v8::internal::NameDictionary, v8::internal::NameDictionaryShape, v8::internal::Handle<v8::internal::Name> >::EnsureCapacity(v8::internal::Handle<v8::internal::NameDictionary>, int, v8::internal::Handle<v8::internal::Name>) [node]
 8: v8::internal::Dictionary<v8::internal::NameDictionary, v8::internal::NameDictionaryShape, v8::internal::Handle<v8::internal::Name> >::Add(v8::internal::Handle<v8::internal::NameDictionary>, v8::internal::Handle<v8::internal::Name>, v8::internal::Handle<v8::internal::Object>, v8::internal::PropertyDetails, int*) [node]
 9: v8::internal::LookupIterator::ApplyTransitionToDataProperty(v8::internal::Handle<v8::internal::JSObject>) [node]
10: v8::internal::Object::AddDataProperty(v8::internal::LookupIterator*, v8::internal::Handle<v8::internal::Object>, v8::internal::PropertyAttributes, v8::internal::Object::ShouldThrow, v8::internal::Object::StoreFromKeyed) [node]
11: v8::internal::Object::SetProperty(v8::internal::LookupIterator*, v8::internal::Handle<v8::internal::Object>, v8::internal::LanguageMode, v8::internal::Object::StoreFromKeyed) [node]
12: v8::internal::Runtime::SetObjectProperty(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, v8::internal::LanguageMode) [node]
13: v8::internal::Runtime_SetProperty(int, v8::internal::Object**, v8::internal::Isolate*) [node]
14: 0x12f4b2c043a7

As a “hack fix” I’ve been using a cron to manually GC, but it’s not a propper solution. If you want me to grab the heap as it grows let me know.

Thanks for all the great work you’ve done in the Beacon space.

[dstarke]

I’ve added the pull request to address this issue.

As described above, and in the PR, there’s a minor change to the interface for onDiscover(), where a second parameter has been added to contain the actual advertisement contents. The new cache behavior should be in effect when allowDuplicates is true. When allowDuplicates is false, the cache is not swept or cleared, leaving the behavior similar to the way it was before.

These changes also addressed some inconsistencies in how scan responses were being handled relative to the Bluetooth spec.

[dstarke]

I’m testing a set of changes that ages out cached peripheral information after a set amount of time. For the moment, I have it set to do this only when allowDuplicates is true and you are actively scanning.

I’ll publish information about my fork and submit a pull request after I’ve tested it a little more.