Facing issue with Nan::NewBuffer with default callback in electron
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 3.4k
- Forks
- 531
- Avg merge
- 21m
- Merged PRs (30d)
- 1
Description
Hello everybody,
I am facing an issue using Nan::NewBuffer(data, size) in an electron app. However, I am not quite sure if this is an issue with electron or the nan buffer itself.
If this is helpful, I also have an open issue at electron: https://github.com/electron/electron/issues/11479.
Allocating a buffer with Nan::NewBuffer(data, size) causes the electron app to crash with the following stacktrace:
[8764:1219/215240.897:FATAL:partition_alloc.cc(934)] Check failed: page->num_allocated_slots != -1.
Backtrace:
GetHandleVerifier [0x000000013FA66D75+23093]
GetHandleVerifier [0x000000013FAD7803+484547]
(No symbol) [0x000000013FA5E9C4]
IsSandboxedProcess [0x0000000142AD20DD+47312277]
IsSandboxedProcess [0x0000000141A092D7+29712271]
v8::internal::OptimizingCompileDispatcher::Unblock [0x000007FED8511A21+1825]
v8::internal::OptimizingCompileDispatcher::Unblock [0x000007FED8511D42+2626]
v8::internal::AllocationSpaceName [0x000007FED84B7D63+13475]
v8::internal::AllocationSpaceName [0x000007FED84BFB16+45654]
v8::internal::Builtins::WasmStackGuard [0x000007FED84AE567+56759]
v8::internal::AllocationSpaceName [0x000007FED84B823A+14714]
v8::internal::AllocationSpaceName [0x000007FED84B74EB+11307]
v8::internal::AllocationSpaceName [0x000007FED84B697E+8382]
v8::internal::OptimizingCompileDispatcher::IsQueueAvailable [0x000007FED81C0BA9+2841]
v8::internal::ScavengeJob::NotifyIdleTask [0x000007FED81C2092+1794]
v8::internal::GCTracer::AddScopeSample [0x000007FED81B4400+13968]
v8::internal::GCTracer::AddScopeSample [0x000007FED81B40DA+13162]
v8::internal::OptimizingCompileDispatcher::Enabled [0x000007FED81BBF60+3456]
v8::internal::interpreter::Bytecodes::ToString [0x000007FED84EE1EC+2652]
GetHandleVerifier [0x000000013FB05ADD+673693]
IsSandboxedProcess [0x000000014204F721+36291545]
IsSandboxedProcess [0x000000014204E59B+36287059]
IsSandboxedProcess [0x000000014204C01D+36277461]
GetHandleVerifier [0x000000013FB05ADD+673693]
GetHandleVerifier [0x000000013FAA6CF6+285110]
GetHandleVerifier [0x000000013FAA57E0+279712]
GetHandleVerifier [0x000000013FB07A13+681683]
GetHandleVerifier [0x000000013FAA2D4E+268814]
IsSandboxedProcess [0x0000000140149473+3760427]
GetHandleVerifier [0x000000013FDB22BD+3477373]
GetHandleVerifier [0x000000013FDB21B4+3477108]
GetHandleVerifier [0x000000013FB5AA9C+1021788]
(No symbol) [0x000000013F7B7E8F]
IsSandboxedProcess [0x0000000142A2C13F+46632439]
BaseThreadInitThunk [0x00000000774459CD+13]
RtlUserThreadStart [0x000000007767A561+33]
It turns out however, that providing the free callback explicitly as follows seems to work fine:
void callback(char* data, void* hint) {
free(data);
}
...
Nan::NewBuffer(data, size, callback, 0)
Any help would be highly appreciated, as I am facing this issue for quite a while now.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No repository file or test is named. Start by reproducing the crash with Nan::NewBuffer(data, size) in Electron, then compare it with the explicit free callback and review Nan's buffer implementation alongside the linked Electron issue. Done means identifying the owning project and establishing a reproducible fix or clear upstream handoff.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, electron
- Domain
- desktop, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100