GithubHelp home page GithubHelp logo

mmap-object's People

Contributors

allenluce avatar druide avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

mmap-object's Issues

Crash on macos

I am trying to use the library, but - at least on macOS Monterey 12.6.3 (21G419) - it crashes, no matter the file size. This is the code I am using:

import Shared from "mmap-object";

const test = new Shared.Open("/tmp/test.txt");
var test = new _mmapObject["default"].Open("/tmp/test.txt");
           ^

Error: Can't open file /tmp/test.txt: boost::interprocess_exception::library_error
    at Object.<anonymous> (/Users/xxx/Documents/xxx/src/xxx/src/api/api.js:22:14)
    at Module._compile (internal/modules/cjs/loader.js:1072:14)
    at Module._compile (/Users/xxx/Documents/xxx/src/xxx/node_modules/pirates/lib/index.js:136:24)
    at Module._extensions..js (internal/modules/cjs/loader.js:1101:10)
    at Object.newLoader [as .js] (/Users/xxx/Documents/xxx/src/xxx/node_modules/pirates/lib/index.js:141:7)
    at Module.load (internal/modules/cjs/loader.js:937:32)
    at Function.Module._load (internal/modules/cjs/loader.js:778:12)
    at Module.require (internal/modules/cjs/loader.js:961:19)
    at require (internal/modules/cjs/helpers.js:92:18)
    at Object.<anonymous> (/Users/xxx/Documents/xxx/src/xxx/src/server.js:6:1)
[nodemon] app crashed - waiting for file changes before starting...

Same goes if I use:

const test = new Shared.Create("/tmp/test.txt");

sigabrt raised calling `new Create()` when running with v8 inspector

Hey, thanks for putting this module out! I ran into an issue trying to debug a script via v8's inspector protocol. As soon as I call new shared.Create(), the script aborts with the following assertion:

node: ../node_modules/nan/nan_object_wrap.h:33: static T* Nan::ObjectWrap::Unwrap(v8::Local<v8::Object>) [with T = SharedMap]: Assertion `object->InternalFieldCount() > 0' failed.

I'm on Ubuntu 18.04 and node v10.11.0, just doing node --inspect-brk my-script.js. It happens both on my host machine and inside docker. I've attached the relevant bits of the v8 backtrace here in case it helps:

(llnode) v8 bt * thread #1: tid = 18842, 0x00007f572b3e8e97 libc.so.6`__GI_raise(sig=2) at raise.c:51, name = 'node', stop reason = signal SIGABRT * frame #0: 0x00007f572b3e8e97 libc.so.6`__GI_raise(sig=2) at raise.c:51 frame #1: 0x00007f572b3ea801 libc.so.6`__GI_abort at abort.c:79 frame #2: 0x00007f572b3da39a libc.so.6`__assert_fail_base(fmt="", assertion="", file="", line=33, function=) at assert.c:92 frame #3: 0x00007f572b3da412 libc.so.6`__GI___assert_fail(assertion=, file=, line=, function=) at assert.c:101 frame #4: 0x00007f5713ddadc6 mmap-object.node`SharedMap* Nan::ObjectWrap::Unwrap(v8::Local) + 118 frame #5: 0x00007f5713dd4738 mmap-object.node`SharedMap::PropEnumerator(Nan::PropertyCallbackInfo const&) + 72 frame #6: 0x00007f5713dd27d5 mmap-object.node`Nan::imp::PropertyEnumeratorCallbackWrapper(v8::PropertyCallbackInfo const&) + 133 frame #7: 0x0000000000fcb50b node`v8::internal::(anonymous namespace)::CollectInterceptorKeysInternal(v8::internal::Handle, v8::internal::Handle, v8::internal::Handle, v8::internal::KeyAccumulator*, v8::internal::(anonymous namespace)::IndexedOrNamed) + 939 frame #8: 0x0000000000fcdab5 node`v8::internal::KeyAccumulator::CollectOwnPropertyNames(v8::internal::Handle, v8::internal::Handle) + 949 frame #9: 0x0000000000fce4f4 node`v8::internal::KeyAccumulator::CollectOwnKeys(v8::internal::Handle, v8::internal::Handle) + 292 frame #10: 0x0000000000fcf1a5 node`v8::internal::KeyAccumulator::CollectKeys(v8::internal::Handle, v8::internal::Handle) + 69 frame #11: 0x0000000000fcf4d6 node`v8::internal::KeyAccumulator::GetKeys(v8::internal::Handle, v8::internal::KeyCollectionMode, v8::internal::PropertyFilter, v8::internal::GetKeysConversion, bool, bool) + 166 frame #12: 0x00000000011900af node`v8::internal::Runtime_ObjectKeys(int, v8::internal::Object**, v8::internal::Isolate*) + 143 frame #13: 0x000009916b4dc01d frame #14: 0x000009916b51feb5 frame #15: 0x000009916b4918b5 _propertyDescriptors(this=0x000039dbef6a7719:, 0x00000cf5efd41f71:, 0x000024aa0775af79:, 0x000008b7954829a1:, 0x000008b7954826f1:, 0x000008b7954826f1:) at (no script):48:120 fn=0x000004b3e63191d1 frame #16: 0x000009916b4918b5 _generatePreview(this=0x000024aa0775ae51:, 0x00000cf5efd41f71:, 0x000008b7954826f1:, 0x000008b7954826f1:, 0x000008b7954826f1:, 0x000008b7954826f1:) at (no script):152:74 fn=0x000004b3e63194e9 frame #17: 0x000009916b4918b5 InjectedScript.RemoteObject(this=0x000024aa0775ae51:, 0x00000cf5efd41f71:, 0x000024aa07729d41:, 0x000008b7954826f1:, 0x000008b7954829a1:, 0x000008b7954828c9:, 0x000008b7954826f1:, 0x000008b7954826f1:, 0x000008b7954826f1:, 0x000008b7954826f1:) at (no script):125:77 fn=0x000028a05167d7d1 frame #18: 0x000009916b48d02f frame #19: 0x000009916b5078e0 frame #20: 0x000009916b4918b5 _wrapObject(this=0x000039dbef6a7719:, 0x00000cf5efd41f71:, 0x000024aa07729d41:, 0x000008b7954829a1:, 0x000008b7954828c9:, 0x000008b7954826f1:, 0x000008b7954826f1:, 0x000008b7954826f1:, 0x000008b7954826f1:) at (no script):34:92 fn=0x000004b3e63190d1 frame #21: 0x000009916b48a5a3 frame #22: 0x000009916b4918b5 getProperties(this=0x000039dbef6a7719:, 0x00000cf5efd4ba89:, 0x000024aa07729d41:, 0x000008b7954829a1:, 0x000008b7954829a1:, 0x000008b7954828c9:) at (no script):37:151 fn=0x000004b3e6319151 frame #23: 0x000009916b48ee55 frame #24: 0x000009916b489521 frame #25: 0x0000000000e9ae33 node`v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::Handle, v8::internal::Handle, int, v8::internal::Handle*) + 259 frame #26: 0x0000000000b28599 node`v8::Function::Call(v8::Local, v8::Local, int, v8::Local*) + 377 frame #27: 0x0000000000acdabf node`v8_inspector::V8FunctionCall::callWithoutExceptionHandling() + 511 frame #28: 0x0000000000a99408 node`v8_inspector::InjectedScript::getProperties(v8::Local, v8_inspector::String16 const&, bool, bool, bool, std::unique_ptr, std::default_delete > >*, v8_inspector::protocol::Maybe*) + 312 frame #29: 0x0000000000aebbbe node`v8_inspector::V8RuntimeAgentImpl::getProperties(v8_inspector::String16 const&, v8_inspector::protocol::Maybe, v8_inspector::protocol::Maybe, v8_inspector::protocol::Maybe, std::unique_ptr, std::default_delete > >*, v8_inspector::protocol::Maybe >*, v8_inspector::protocol::Maybe*) + 318 frame #30: 0x0000000000a847f9 node`v8_inspector::protocol::Runtime::DispatcherImpl::getProperties(int, std::unique_ptr >, v8_inspector::protocol::ErrorSupport*) + 889 frame #31: 0x0000000000a86eea node`v8_inspector::protocol::Runtime::DispatcherImpl::dispatch(int, v8_inspector::String16 const&, std::unique_ptr >) + 218 frame #32: 0x0000000000a4b3ca node`v8_inspector::protocol::UberDispatcher::dispatch(std::unique_ptr >, int*, v8_inspector::String16*) + 1850 frame #33: 0x0000000000ad7e56 node`v8_inspector::V8InspectorSessionImpl::dispatchProtocolMessage(v8_inspector::StringView const&) + 38 frame #34: 0x00000000009ccced node`node::inspector::(anonymous namespace)::SameThreadInspectorSession::Dispatch(v8_inspector::StringView const&) + 413 frame #35: 0x00000000009e5bb6 node`node::inspector::(anonymous namespace)::MainThreadSessionState::Dispatch(std::unique_ptr >) + 182 frame #36: 0x00000000009e3b8e node`void node::inspector::(anonymous namespace)::AnotherThreadObjectReference::Apply > >(node::inspector::(anonymous namespace)::MainThreadSessionState*, void (node::inspector::(anonymous namespace)::MainThreadSessionState::*)(std::unique_ptr >), std::unique_ptr >&) + 46 frame #37: 0x00000000009e3eec node`node::inspector::MainThreadInterface::DispatchMessages() (.part.183) + 76 frame #38: 0x000000000095aa44 node`node::PerIsolatePlatformData::RunForegroundTask(std::unique_ptr >) + 132 frame #39: 0x000000000095bd32 node`node::PerIsolatePlatformData::FlushForegroundTasksInternal() + 514 frame #40: 0x000000000095c658 node`node::NodePlatform::FlushForegroundTasks(v8::Isolate*) + 104 frame #41: 0x00000000009cf985 node`node::inspector::NodeInspectorClient::runMessageLoopOnPause(int) + 229 frame #42: 0x0000000000ab9260 node`v8_inspector::V8Debugger::BreakProgramRequested(v8::Local, v8::Local, std::vector > const&) + 1088 frame #43: 0x0000000000e49722 node`v8::internal::Debug::OnDebugBreak(v8::internal::Handle) + 466 frame #44: 0x0000000000e4a098 node`v8::internal::Debug::HandleDebugBreak(v8::internal::IgnoreBreakMode) + 728 frame #45: 0x000000000114d222 node`v8::internal::Runtime_HandleDebuggerStatement(int, v8::internal::Object**, v8::internal::Isolate*) + 66 frame #46: 0x000009916b4dc01d frame #47: 0x000009916b493a83 frame #48: 0x000009916b651c52

High Memory Usage with Large Text Files

Hello,
I am experiencing high memory usage issues while using the npm package mmap-object for analyzing large files. The library takes too much memory, twice or for larger files even three or four times.

I have created a public GitHub repository where I have uploaded a test application to demonstrate the issue, available at https://github.com/monteiz/mmap-object-memory-issue. The text file used in the test application is ASCII encoded and should take only one byte for each character.

Here are the relevant logs produced by the test application:

Text file size: 40 MiB
Analysing master random_strings.txt on pid 14118...
Lines count: 107957

Master file for random_strings.txt successfully analysed.

Processed byte: 40 MiB
RSS: 91 MiB
HeapTotal: 12 MiB
HeapUsed: 5.5 MiB
External: 2.2 MiB
ArrayBuffers: 1.2 MiB

As shown in the logs, the analyzed file size is 40 MiB, but the memory usage is much higher, with the RSS being 91 MiB.

Expected behavior

The mmap-object library should not use more memory than necessary when analyzing large files. It should be able to handle large files without requiring excessive amounts of memory.

Actual behavior

The mmap-object library is using significantly more memory than expected, with memory usage often two or three times the size of the analyzed file.


I believe this is a significant issue for anyone working with large files, and I hope it can be resolved soon.

Licensing

I happened across this project looking for a mmap'ed kv-store to use to consume a lot of data from a kafka source and -- at least from some naive initial testing -- it looks like exactly what I'm looking for!

Unfortunately, it does seem though that this code is UNLICENSED which means that (generally speaking) it cannot be used in derivative works -- at least according to some naive initial research*.

I presume -- due to your stackoverflow plug -- that it was not your intent to limit the use of this project/package. Is that correct, and if so, can I "twist your arm" into adding a more explicitly-permissive license?


(*) Specifically this stackexchange thread and gnu's license-list.

I have been trying to install the module with no luck

I dont Know what is the real problem. Looks like its trying to execute node but not finding it maybe. Dunno any ideas?

Error:

npm install mmap-object

> [email protected] install F:\ARBITTREX\crypto-arb-priv\node_modules\mmap-object
> node-pre-gyp install --fallback-to-build

node-pre-gyp ERR! Tried to download(404): https://github.com/allenluce/mmap-object/releases/downlo
ad/1.3.5/mmap-object-v1.3.5-node-v57-win32-x64.tar.gz
node-pre-gyp ERR! Pre-built binaries not found for [email protected] and [email protected] (node-v57 ABI)
 (falling back to source compile with node-gyp)
Building the projects in this solution one at a time. To enable parallel build, please add the "/m
" switch.
  mmap-object.cc
  win_delay_load_hook.cc
..\mmap-object.cc(11): fatal error C1083: Cannot open include file: 'boost/interprocess/managed_m
apped_file.hpp': No such file or directory [F:\ARBITTREX\crypto-arb-priv\node_modules\mmap-object
\build\mmap-object.vcxproj]
gyp ERR! build error
gyp ERR! stack Error: `C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe` failed with exit code:
 1
gyp ERR! stack     at ChildProcess.onExit (F:\ARBITTREX\crypto-arb-priv\node_modules\node-gyp\lib\
build.js:258:23)
gyp ERR! stack     at emitTwo (events.js:125:13)
gyp ERR! stack     at ChildProcess.emit (events.js:213:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:197:12)
gyp ERR! System Windows_NT 10.0.14393
gyp ERR! command "F:\\Program Files\\nodejs\\node.exe" "F:\\ARBITTREX\\crypto-arb-priv\\node_modul
es\\node-gyp\\bin\\node-gyp.js" "build" "--fallback-to-build" "--module=F:\\ARBITTREX\\crypto-arb-
priv\\node_modules\\mmap-object\\lib\\mmap-object.node" "--module_name=mmap-object" "--module_path
=F:\\ARBITTREX\\crypto-arb-priv\\node_modules\\mmap-object\\lib"
gyp ERR! cwd F:\ARBITTREX\crypto-arb-priv\node_modules\mmap-object
gyp ERR! node -v v8.1.3
gyp ERR! node-gyp -v v3.6.2
gyp ERR! not ok
node-pre-gyp ERR! build error
node-pre-gyp ERR! stack Error: Failed to execute 'F:\Program Files\nodejs\node.exe F:\ARBITTREX\cr
ypto-arb-priv\node_modules\node-gyp\bin\node-gyp.js build --fallback-to-build --module=F:\ARBITTRE
X\crypto-arb-priv\node_modules\mmap-object\lib\mmap-object.node --module_name=mmap-object --module
_path=F:\ARBITTREX\crypto-arb-priv\node_modules\mmap-object\lib' (1)
node-pre-gyp ERR! stack     at ChildProcess.<anonymous> (F:\ARBITTREX\crypto-arb-priv\node_modules
\node-pre-gyp\lib\util\compile.js:83:29)
node-pre-gyp ERR! stack     at emitTwo (events.js:125:13)
node-pre-gyp ERR! stack     at ChildProcess.emit (events.js:213:7)
node-pre-gyp ERR! stack     at maybeClose (internal/child_process.js:897:16)
node-pre-gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:208:
5)
node-pre-gyp ERR! System Windows_NT 10.0.14393
node-pre-gyp ERR! command "F:\\Program Files\\nodejs\\node.exe" "F:\\ARBITTREX\\crypto-arb-priv\\n
ode_modules\\node-pre-gyp\\bin\\node-pre-gyp" "install" "--fallback-to-build"
node-pre-gyp ERR! cwd F:\ARBITTREX\crypto-arb-priv\node_modules\mmap-object
node-pre-gyp ERR! node -v v8.1.3
node-pre-gyp ERR! node-pre-gyp -v v0.6.37
node-pre-gyp ERR! not ok
Failed to execute 'F:\Program Files\nodejs\node.exe F:\ARBITTREX\crypto-arb-priv\node_modules\node
-gyp\bin\node-gyp.js build --fallback-to-build --module=F:\ARBITTREX\crypto-arb-priv\node_modules\
mmap-object\lib\mmap-object.node --module_name=mmap-object --module_path=F:\ARBITTREX\crypto-arb-p
riv\node_modules\mmap-object\lib' (1)
npm WARN [email protected] license should be a valid SPDX license expression

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] install: `node-pre-gyp install --fallback-to-build`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\Manu\AppData\Roaming\npm-cache\_logs\2017-09-16T19_45_14_634Z-debug.log

Some valid PropGet calls fail due to use of aho_corasick::trie

In mmao-object.cc, the PropGetter function wants to ensure that the property name is not in the list of method names created by the buildMethods() function.

The problem is that methodTrie.contains(string(*src)) returns true if the property name has a substring that matches one of the reserved method names.

For example, if I set a property named "xxxclosexxx", the set will succeed. However the PropGetter call will fail because "xxxclosexxx" contains the substring "close", and "close is stored in aho_corasick::trie methodTrie.

is delete process-safe ?

the case:
write shared memory in one proccess
read and delete property in another process

is this safe ?

v1.4.2 not published to NPM

Adding the line "mmap-object": "^1.4.2" to an app's package.json and running npm install results in the error:

npm ERR! code ETARGET
npm ERR! notarget No matching version found for mmap-object@^1.4.2.
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.

This is important as v1.4.1 is not compatible with Node v12.

Build failed on node 10

Short log:

CXX(target) Release/obj.target/mmap-object/mmap-object.o
../mmap-object.cc: In static member function ‘static Nan::NAN_PROPERTY_SETTER_RETURN_TYPE SharedMap::PropSetter(v8::Local<v8::String>, v8::Local<v8::Value>, Nan::NAN_PROPERTY_SETTER_ARGS_TYPE)’:
../mmap-object.cc:240:43: error: ‘v8::String::Utf8Value::Utf8Value(v8::Local<v8::Value>)’ is deprecated: Use Isolate version [-Werror=deprecated-declarations]
           v8::String::Utf8Value data(value);
                                           ^
In file included from /home/darky/.node-gyp/10.0.0/include/node/v8.h:26:0,
                 from /home/darky/.node-gyp/10.0.0/include/node/node.h:63,
                 from ../../nan/nan.h:51,
                 from ../mmap-object.cc:16:
/home/darky/.node-gyp/10.0.0/include/node/v8.h:2822:28: note: declared here
                   explicit Utf8Value(Local<v8::Value> obj));
                            ^
/home/darky/.node-gyp/10.0.0/include/node/v8config.h:318:3: note: in definition of macro ‘V8_DEPRECATED’
   declarator __attribute__((deprecated(message)))
   ^~~~~~~~~~

throw exception if shared object is created again

Currently if a shared object is created twice, no error/exception is thrown.
Is it possible to throw an error for the second call?

Example:
shared_object1 = new Shared.Create('filename')

call the following in another process:
shared_object2 = new Shared.Create('filename') // this should lead to error

Many thanks!

Getting an error after uploading server to Amazon ECS.

It works locally but when I upload it, I'm seeing these errors in the logs:

{ [Error: ENOENT: no such file or directory, open '.env'] errno: -2, code: 'ENOENT', syscall: 'open', path: '.env' } <==== (I'm not sure if this one is related to mmap-object)

Error: Error relocating /usr/src/app/node_modules/mmap-object/lib/mmap-object.node: __open64_2: symbol not found.

Thanks!

Keys starting with numbers don't seem to be persisted

const mmap = require('mmap-object');
var file = '/tmp/a';
var store = new mmap.Create(file);
store['12345'] = "test test test";
store.close();

var read = new mmap.Open(file);
console.log(read['12345']) //undefined;

Pretty trivial to work around on the JS side so maybe its worth just documenting it?

Production safe?

I have some stuff that is too slow to pull out of Redis (50mb stringified + parsing is slow) that I need to share between processes. Is this the answer? Is this used in any production apps?

crashed

os: a customised linux mint distro, i don't know what version exactly is. if you need any information else, please let me know.

Thread 0 (crashed)
 0  libpthread.so.0 + 0x9de0
    rax = 0xffffffffffffffff   rdx = 0x000058579ce18eb8
    rcx = 0x00007ffd97a84c78   rbx = 0x00007f2bc641f010
    rsi = 0x00007f2bc6967300   rdi = 0x00007f2bc641f010
    rbp = 0x00007ffd97a84c60   rsp = 0x00007ffd97a84c38
     r8 = 0x000058579d361190    r9 = 0x0000000000151818
    r10 = 0x000026d428be1731   r11 = 0xffffffffffffffff
    r12 = 0x00007f2bc6967300   r13 = 0x00007ffd97a84dc0
    r14 = 0x0000000000151800   r15 = 0x000026d428be1728
    rip = 0x00007f2be3f24de0
    Found by: given as instruction pointer in context
 1  mmap-object.node!boost::container::container_detail::basic_string_base<boost::interprocess::allocator<char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::~basic_string_base() + 0x65
    rbp = 0x00007ffd97a84c80   rsp = 0x00007ffd97a84c70
    rip = 0x00007f2bc6e87c25
    Found by: previous frame's frame pointer
 2  mmap-object.node!Cell::SetValue(v8::Local<v8::Value>, boost::interprocess::basic_managed_mapped_file<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index>*, std::unique_ptr<Cell, std::default_delete<Cell> >&, Nan::PropertyCallbackInfo<v8::Value> const&) + 0x739
    rbp = 0x00007ffd97a84d50   rsp = 0x00007ffd97a84c90
    rip = 0x00007f2bc6e90609
    Found by: call frame info
 3  mmap-object.node!SharedMap::PropSetter(v8::Local<v8::String>, v8::Local<v8::Value>, Nan::PropertyCallbackInfo<v8::Value> const&) + 0xc6
    rbx = 0x000026d42bffdd90   rbp = 0x00007ffd97a84f10
    rsp = 0x00007ffd97a84d60   r12 = 0x00007ffd97a85120
    r13 = 0x000026d427f7a110   r14 = 0x00007ffd97a84e10
    r15 = 0x00007ffd97a85440   rip = 0x00007f2bc6e7bb46
    Found by: call frame info
 4  mmap-object.node!SharedMap::IndexSetter(unsigned int, v8::Local<v8::Value>, Nan::PropertyCallbackInfo<v8::Value> const&) + 0xb1
    rbx = 0x00007ffd97a84f50   rbp = 0x00007ffd97a85100
    rsp = 0x00007ffd97a84f20   r12 = 0x00007ffd97a84f40
    r13 = 0x000026d42717a090   r14 = 0x00007ffd97a85440
    r15 = 0x00007ffd97a85120   rip = 0x00007f2bc6e7c151
    Found by: call frame info
 5  mmap-object.node!Nan::imp::IndexSetterCallbackWrapper(unsigned int, v8::Local<v8::Value>, v8::PropertyCallbackInfo<v8::Value> const&) + 0x92
    rbx = 0x00000afcbe24fa29   rbp = 0x00007ffd97a85160
    rsp = 0x00007ffd97a85110   r12 = 0x0000000000000002
    r13 = 0x00007ffd97a85440   r14 = 0x00007ffd97a85268
    r15 = 0x00007ffd97a85200   rip = 0x00007f2bc6e76ac2
    Found by: call frame info

Why is object available after close()?

Probably missing something, but following the given example new Shared.Open('filename') is done after shared_object.close() is performed. Indeed this works.

I assumed doing shared_object.close() would free up the the shared object, thus making it unavailable for new Shared.Open('filename') . Why is it still available?

Underlying question: how can I be sure that objects are removed from memory?

Support node 6?

Unfortunately i have some modules which requires node 6, but the latest version i managed to install mmap was 5.

How hard would be to update it to be compatible with 6?

Thank You

Problem building on Linux ARM

I'm trying to install the module on a Linux ARM platform but I'm running into a symbol versioning issue:

/usr/bin/ld: Release/obj.target/mmap-object.node: No symbol version section for versioned symbol `memcpy@GLIBC_2.2.5'
/usr/bin/ld: final link failed: Nonrepresentable section on output
...

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.