macOS 11.2: Fatal error `Check failed: allocator->SetPermissions` #37061

andreialecu · 2021-01-25T09:07:56Z

Version: v15.6.0
Platform: Darwin Andreis-Mac-mini.local 20.3.0 Darwin Kernel Version 20.3.0: Thu Jan 14 14:38:22 PST 2021; root:xnu-7195.81.2~2/RELEASE_ARM64_T8101 arm64
Subsystem: wasm(?)

What steps will reproduce the bug?

Use latest macOS Beta 11.2 (released 24 Jan 2021) and node 15.6.0

npm install -g yarn
cd `mktemp -d`
yarn init -2
yarn add lodash

How often does it reproduce? Is there a required condition?

All the time.

What is the expected behavior?

No crash.

What do you see instead?

#
# Fatal error in , line 0
# Check failed: allocator->SetPermissions(reinterpret_cast<void*>(region.begin()), region.size(), PageAllocator::kNoAccess).
#
#
#
#FailureMessage Object: 0x16f986408
 1: 0x100575758 node::NodePlatform::GetStackTracePrinter()::$_3::__invoke() [/Users/andreialecu/.nvm/versions/node/v15.6.0/bin/node]
 2: 0x1012bdd50 V8_Fatal(char const*, ...) [/Users/andreialecu/.nvm/versions/node/v15.6.0/bin/node]
 3: 0x100c0fb98 v8::internal::wasm::WasmCodeManager::Decommit(v8::base::AddressRegion) [/Users/andreialecu/.nvm/versions/node/v15.6.0/bin/node]
 4: 0x100c13218 v8::internal::wasm::NativeModule::FreeCode(v8::internal::Vector<v8::internal::wasm::WasmCode* const>) [/Users/andreialecu/.nvm/versions/node/v15.6.0/bin/node]
 5: 0x100c22400 v8::internal::wasm::WasmEngine::FreeDeadCodeLocked(std::__1::unordered_map<v8::internal::wasm::NativeModule*, std::__1::vector<v8::internal::wasm::WasmCode*, std::__1::allocator<v8::internal::wasm::WasmCode*> >, std::__1::hash<v8::internal::wasm::NativeModule*>, std::__1::equal_to<v8::internal::wasm::NativeModule*>, std::__1::allocator<std::__1::pair<v8::internal::wasm::NativeModule* const, std::__1::vector<v8::internal::wasm::WasmCode*, std::__1::allocator<v8::internal::wasm::WasmCode*> > > > > const&) [/Users/andreialecu/.nvm/versions/node/v15.6.0/bin/node]
 6: 0x100c20108 v8::internal::wasm::WasmEngine::PotentiallyFinishCurrentGC() [/Users/andreialecu/.nvm/versions/node/v15.6.0/bin/node]
 7: 0x100c2157c v8::internal::wasm::WasmEngine::ReportLiveCodeForGC(v8::internal::Isolate*, v8::internal::Vector<v8::internal::wasm::WasmCode*>) [/Users/andreialecu/.nvm/versions/node/v15.6.0/bin/node]
 8: 0x100c23d20 v8::internal::wasm::(anonymous namespace)::WasmGCForegroundTask::RunInternal() [/Users/andreialecu/.nvm/versions/node/v15.6.0/bin/node]
 9: 0x100573bf4 node::PerIsolatePlatformData::RunForegroundTask(std::__1::unique_ptr<v8::Task, std::__1::default_delete<v8::Task> >) [/Users/andreialecu/.nvm/versions/node/v15.6.0/bin/node]
10: 0x10057288c node::PerIsolatePlatformData::FlushForegroundTasksInternal() [/Users/andreialecu/.nvm/versions/node/v15.6.0/bin/node]
11: 0x100d551a8 uv__async_io [/Users/andreialecu/.nvm/versions/node/v15.6.0/bin/node]
12: 0x100d66d68 uv__io_poll [/Users/andreialecu/.nvm/versions/node/v15.6.0/bin/node]
13: 0x100d55638 uv_run [/Users/andreialecu/.nvm/versions/node/v15.6.0/bin/node]
14: 0x100472bd0 node::SpinEventLoop(node::Environment*) [/Users/andreialecu/.nvm/versions/node/v15.6.0/bin/node]
15: 0x10054caf4 node::NodeMainInstance::Run(node::EnvSerializeInfo const*) [/Users/andreialecu/.nvm/versions/node/v15.6.0/bin/node]
16: 0x1004ecc20 node::Start(int, char**) [/Users/andreialecu/.nvm/versions/node/v15.6.0/bin/node]
17: 0x199435f34 start [/usr/lib/system/libdyld.dylib]

Additional information

This started happening after the macOS beta update I think. I was on beta before, but everything was working fine until after the update.

I'm on an ARM64 M1 chip (mac mini 16gb ram)

node/deps/v8/src/wasm/wasm-code-manager.cc

Lines 1630 to 1631 in 770d9e2

    
           CHECK(allocator->SetPermissions(reinterpret_cast<void*>(region.begin()), 
        
                                           region.size(), PageAllocator::kNoAccess));

The text was updated successfully, but these errors were encountered:

andreialecu · 2021-01-25T20:08:30Z

Some additional information:

It appears that nodejs 15.6 runs on v8 8.6, sharing the same V8 version with Chromium 86.
I installed Chromium 86 to test WASM, and it crashes there too.
However, Chromium 88+ which use v8 8.8 do not have the crash.

See microsoft/vscode#113410 (comment) for more details.

GautierT · 2021-01-26T09:42:36Z

@andreialecu : did you find a workaround ? Thanks !

andreialecu · 2021-01-26T09:48:43Z

Unfortunately no. I had to revert to nodejs 14, using Rosetta. Hopefully only temporarily.

arch -x86_64 zsh

nvm install 14
nvm alias default 14
exit

GautierT · 2021-01-26T09:50:17Z

yes i did the same but sad to have to use back Rosetta... Thanks.

EriksRemess · 2021-01-26T10:37:23Z

Same crash happens on latest MacOS 11.2 RC2 (20D62).

Update:
Node v15.7.0 released today has the same issue.

MarcoZehe · 2021-01-26T15:22:05Z

Thanks for filing this and investigating the cause, @andreialecu . I am running into this when trying to run the Netlify CLI.

matinzd · 2021-01-28T17:13:18Z

I also have this problem on apple silicon node v 15.7.0.

System info

Darwin Matins-MacBook-Pro.local 20.3.0 Darwin Kernel Version 20.3.0: Thu Jan 14 14:38:22 PST 2021; root:xnu-7195.81.2~2/RELEASE_ARM64_T8101 arm64

Error:

$ react-native start

#
# Fatal error in , line 0
# Check failed: allocator->SetPermissions(reinterpret_cast<void*>(region.begin()), region.size(), PageAllocator::kNoAccess).
#
#
#
#FailureMessage Object: 0x16efd4748
 1: 0x100f09044 node::NodePlatform::GetStackTracePrinter()::$_3::__invoke() [/opt/homebrew/Cellar/node/15.7.0/bin/node]
 2: 0x101890fdc V8_Fatal(char const*, ...) [/opt/homebrew/Cellar/node/15.7.0/bin/node]

panr · 2021-01-29T08:17:56Z

Big Sur 11.2 RC3 doesn't change anything. Still get the same error...

andreialecu · 2021-01-29T08:38:36Z

@aduh95 apologies for tagging you on this, but given your mac arm64 commits, perhaps you would know who to forward this to since it is a very serious problem.

11.2 will be out any day now and this will hit a lot of people.

panr · 2021-01-29T08:46:56Z

I just reported this directly to Apple. Will see what happens...

andreialecu · 2021-01-29T08:51:23Z

I also reported it to Apple several days ago but that's usually a black hole.

I'm inclined to believe that v8 is doing something wrong here, because recent Chrome versions don't have this issue, but older Chrome versions do (ones which use the same v8 version as node). See #37061 (comment) and microsoft/vscode#113410 (comment)

aduh95 · 2021-01-29T09:25:12Z

@aduh95 apologies for tagging you on this, but given your mac arm64 commits, perhaps you would know who to forward this to since it is a very serious problem.

11.2 will be out any day now and this will hit a lot of people.

Unfortunately I don't have M1 macs at my disposal anymore.

If the problem is the V8 version, could you try compile node with a more recent one? You can try out the V8 8.8 PR which is almost ready now:

# on a local git repo sync with the latest master
curl -L https://github.com/nodejs/node/pull/36139.patch | git am
make -j8

andreialecu · 2021-01-29T10:30:35Z

Thanks for the tip @aduh95, I built it but it doesn't seem to be enough:

➜ which node
/Users/andreialecu/Work/contrib/node/node

➜ node -v
v16.0.0-pre

➜ yarn install

...
#
# Fatal error in , line 0
# Check failed: allocator->SetPermissions(reinterpret_cast<void*>(region.begin()), region.size(), PageAllocator::kNoAccess).
#
#
#
#FailureMessage Object: 0x16db051f8
 1: 0x1023feb58 node::NodePlatform::GetStackTracePrinter()::$_3::__invoke() [/Users/andreialecu/Work/contrib/node/out/Release/node]
 2: 0x103150998 V8_Fatal(char const*, ...) [/Users/andreialecu/Work/contrib/node/out/Release/node]
 3: 0x102aa8710 v8::internal::wasm::WasmCodeManager::Decommit(v8::base::AddressRegion) [/Users/andreialecu/Work/contrib/node/out/Release/node]
 4: 0x102aac384 v8::internal::wasm::NativeModule::FreeCode(v8::internal::Vector<v8::internal::wasm::WasmCode* const>) [/Users/andreialecu/Work/contrib/node/out/Release/node]
 5: 0x102abb448 v8::internal::wasm::WasmEngine::FreeDeadCodeLocked(std::__1::unordered_map<v8::internal::wasm::NativeModule*, std::__1::vector<v8::internal::wasm::WasmCode*, std::__1::allocator<v8::internal::wasm::WasmCode*> >, std::__1::hash<v8::internal::wasm::NativeModule*>, std::__1::equal_to<v8::internal::wasm::NativeModule*>, std::__1::allocator<std::__1::pair<v8::internal::wasm::NativeModule* const, std::__1::vector<v8::internal::wasm::WasmCode*, std::__1::allocator<v8::internal::wasm::WasmCode*> > > > > const&) [/Users/andreialecu/Work/contrib/node/out/Release/node]

aduh95 · 2021-01-29T10:46:13Z

@andreialecu What does node -p process.versions.v8 returns? If you visit chrome://version/ on a Chromium-browser that doesn't have the bug, what V8 version is it running?

andreialecu · 2021-01-29T10:51:58Z

➜ node -p process.versions.v8
8.8.278.14-node.21


Google Chrome | 88.0.4324.96 (Official Build) (arm64)
-- | --
Revision | 68dba2d8a0b149a1d3afac56fa74648032bcf46b-refs/branch-heads/4324@{#1784}
OS | macOS Version 11.2 (Build 20D53)
JavaScript | V8 8.8.278.14

Seems to be exactly the same.

I'm not sure if I tested this properly, or if Chromium 86 had a different issue, but I mentioned here what I did: microsoft/vscode#113410 (comment)

aduh95 · 2021-01-29T10:57:33Z

The yarn install part of the repro makes it a bit tedious to reproduce, any chance you are able to provide a smaller repro? Maybe a simple out/Release/node test/parallel/test-wasm-simple.js would be enough?

andreialecu · 2021-01-29T11:13:17Z

➜ out/Release/node test/parallel/test-wasm-simple.js seems to complete without errors. I assume there's some different code path that ends up being used when using yarn install.

To others in this thread:

What are you running to get this crash?
Is everyone on Apple Silicon or does it happen on Intel as well?

matinzd · 2021-01-29T11:52:05Z

➜ out/Release/node test/parallel/test-wasm-simple.js seems to complete without errors. I assume there's some different code path that ends up being used when using yarn install.

To others in this thread:

What are you running to get this crash?

Is everyone on Apple Silicon or does it happen on Intel as well?

Just Apple Silicon. No problem on Intel. Happens in some projects.

andreialecu · 2021-01-29T11:52:36Z

@aduh95 Some additional info.

Removing the CHECK() from this line:

node/deps/v8/src/wasm/wasm-code-manager.cc

Lines 1630 to 1631 in 770d9e2

    
           CHECK(allocator->SetPermissions(reinterpret_cast<void*>(region.begin()), 
        
                                           region.size(), PageAllocator::kNoAccess));

Resolves the problem, as expected. I'm able to run yarn properly and other commands.

Why it fails though, is a mistery. I went through a bit of a rabbit hole reading source to see where it leads to and found this part:

node/deps/v8/src/base/platform/platform-posix.cc

Lines 417 to 421 in b9dfda9

    
           int ret = mprotect(address, size, prot); 
        
           if (ret == 0 && access == OS::MemoryPermission::kNoAccess) { 
        
             // This is advisory; ignore errors and continue execution. 
        
             USE(DiscardSystemPages(address, size)); 
        
           }

I assume mprotect fails and the entire method returns false.

I found this https://bugs.exim.org/show_bug.cgi?id=2618 mentioning mprotect, JIT and Apple Silicon, which may be relevant.

aduh95 · 2021-01-29T12:56:57Z

Possibly related: Probably related: v8/v8@4e077ff

That's the most recent commit that references JIT and aarm64, and was included in V8 8.8.

Would changing this instruction:

node/deps/v8/src/wasm/wasm-code-manager.cc

Lines 1630 to 1631 in 770d9e2

    
           CHECK(allocator->SetPermissions(reinterpret_cast<void*>(region.begin()), 
        
                                           region.size(), PageAllocator::kNoAccess));

to

 CHECK(allocator->SetPermissions(reinterpret_cast<void*>(region.begin()), 
                                 region.size(), PageAllocator::kNoAccessWillJitLater));

solve the issue?

andreialecu · 2021-01-29T13:36:30Z

@aduh95 nope:

# Fatal error in , line 0
# Check failed: allocator->SetPermissions(reinterpret_cast<void*>(region.begin()), region.size(), PageAllocator::kNoAccessWillJitLater).

andreialecu · 2021-01-29T15:50:43Z

So I just tried some random WASM packages from npm using their example scripts and they seem to run properly on 15.6 and on 16-dev. test/parallel/test-wasm-simple.js also succeeds.

So WASM does work to some extent, until that Decommit code path gets called.

I can reproduce it 100% using yarn@^2. I'm not entirely sure what it does differently vs other WASM modules I tested.

This may also indicate that Chrome and recent v8 versions also have the bug, just that it doesn't reproduce as obviously there.

andreialecu · 2021-02-15T10:52:59Z

Here's an easy way to get the patch applied:

Ensure you have nvm installed:

# install nvm if you don't have it:
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.37.2/install.sh | bash

I made a gist of the patch for easy download:

cd ~
curl https://gist.githubusercontent.com/andreialecu/54b17d7872d047a61e85dcf0261a6105/raw/da5b55457533397e178a021ccfbf9cb827da9d8b/node-arm64.diff > node-patch.diff

nvm install 15.8

(if you already have node installed via nvm, you may need to uninstall it first - nvm uninstall 15)

Now, wait for a bit for nvm to download the sources. Keep an eye on the terminal output.

Once it starts compiling, open a second terminal and run the following. You should have plenty of time before it starts compiling the relevant files.

cd ~/.nvm/.cache/src/node-v15.8.0/files
patch -p1 < ~/node-patch.diff

After it's done you can use nvm use 15 before running node commands to ensure it works. If you want to make it the default version for your shells, run nvm alias default 15.8.0

carloskiki · 2021-02-15T14:03:09Z

I built node from source using homebrew brew reinstall --build-from-source node and it seems like it doesn't work.

I still get the error when I use npm start on a react app. Can somebody explain to me why?

goranmoomin · 2021-02-15T15:06:38Z

@Carlosted I haven't used homebrew for a few months (I switched to MacPorts), but you should add --HEAD to your command to compile with the latest source.

andresilva-cc · 2021-02-15T22:34:59Z

@Carlosted I haven't used homebrew for a few months (I switched to MacPorts), but you should add --HEAD to your command to compile with the latest source.

I can confirm that using the command brew install --HEAD node installs v16.0.0-head which already has this fix.

Virgil-N · 2021-02-16T09:42:34Z

New version of Node (15.8.0) fixes issue for me.

Not for me.😂

jakobkummerow · 2021-02-16T11:41:53Z

@adietrichs : That's an unrelated issue. Please file a bug at crbug.com/v8/new and include as much detail as you can (ideally: repro instructions).

Original commit message: [mac][wasm] Work around MacOS 11.2 code page decommit failures MacOS 11.2 refuses to set "no access" permissions on memory that we previously used for JIT-compiled code. It is still unclear whether this is WAI on the part of the kernel. In the meantime, as a workaround, we use madvise(..., MADV_FREE_REUSABLE) instead of mprotect(..., NONE) when discarding code pages. This is inspired by what Chromium's gin platform does. Fixed: v8:11389 Change-Id: I866586932573b4253002436ae5eee4e0411c45fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679688 Commit-Queue: Jakob Kummerow <[email protected]> Commit-Queue: Michael Lippautz <[email protected]> Auto-Submit: Jakob Kummerow <[email protected]> Reviewed-by: Michael Lippautz <[email protected]> Cr-Commit-Position: refs/heads/master@{#72559} Refs: v8/v8@0c8b6e4 Fixes: #37061 PR-URL: #37276 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ash Cripps <[email protected]>

aduh95 · 2021-02-17T11:41:03Z

The fix should land in Node.js v15.9.0 (expected release date: today).

Please stop commenting the issue is still happening with Node.js v15.8.0, we know, the fix is coming. In the mean time, please wait for v15.9.0 to be released, or build from source, or use the x86_64 version with Rosetta.

etiennecossart · 2021-02-18T04:59:52Z

Just upgraded to v15.9.0 and it resolved the Safari localhost connection issue

karlhorky · 2021-02-18T10:01:09Z

Homebrew Pull Request: Homebrew/homebrew-core#71400

andresilva-cc · 2021-02-18T14:22:04Z

I've uninstalled node --HEAD via brew and installed it again (node@15), and I can confirm that it is working as expected. Thanks, everyone!

Original commit message: [mac][wasm] Work around MacOS 11.2 code page decommit failures MacOS 11.2 refuses to set "no access" permissions on memory that we previously used for JIT-compiled code. It is still unclear whether this is WAI on the part of the kernel. In the meantime, as a workaround, we use madvise(..., MADV_FREE_REUSABLE) instead of mprotect(..., NONE) when discarding code pages. This is inspired by what Chromium's gin platform does. Fixed: v8:11389 Change-Id: I866586932573b4253002436ae5eee4e0411c45fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679688 Commit-Queue: Jakob Kummerow <[email protected]> Commit-Queue: Michael Lippautz <[email protected]> Auto-Submit: Jakob Kummerow <[email protected]> Reviewed-by: Michael Lippautz <[email protected]> Cr-Commit-Position: refs/heads/master@{#72559} Refs: v8/v8@0c8b6e4 Fixes: nodejs#37061 PR-URL: nodejs#37276 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ash Cripps <[email protected]>

Original commit message: [mac][wasm] Work around MacOS 11.2 code page decommit failures MacOS 11.2 refuses to set "no access" permissions on memory that we previously used for JIT-compiled code. It is still unclear whether this is WAI on the part of the kernel. In the meantime, as a workaround, we use madvise(..., MADV_FREE_REUSABLE) instead of mprotect(..., NONE) when discarding code pages. This is inspired by what Chromium's gin platform does. Fixed: v8:11389 Change-Id: I866586932573b4253002436ae5eee4e0411c45fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679688 Commit-Queue: Jakob Kummerow <[email protected]> Commit-Queue: Michael Lippautz <[email protected]> Auto-Submit: Jakob Kummerow <[email protected]> Reviewed-by: Michael Lippautz <[email protected]> Cr-Commit-Position: refs/heads/master@{#72559} Refs: v8/v8@0c8b6e4 Fixes: #37061 PR-URL: #37276 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ash Cripps <[email protected]>

Original commit message: [mac][wasm] Work around MacOS 11.2 code page decommit failures MacOS 11.2 refuses to set "no access" permissions on memory that we previously used for JIT-compiled code. It is still unclear whether this is WAI on the part of the kernel. In the meantime, as a workaround, we use madvise(..., MADV_FREE_REUSABLE) instead of mprotect(..., NONE) when discarding code pages. This is inspired by what Chromium's gin platform does. Fixed: v8:11389 Change-Id: I866586932573b4253002436ae5eee4e0411c45fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679688 Commit-Queue: Jakob Kummerow <[email protected]> Commit-Queue: Michael Lippautz <[email protected]> Auto-Submit: Jakob Kummerow <[email protected]> Reviewed-by: Michael Lippautz <[email protected]> Cr-Commit-Position: refs/heads/master@{#72559} Refs: v8/v8@0c8b6e4 Fixes: nodejs#37061 PR-URL: nodejs#37276 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ash Cripps <[email protected]>

Original commit message: [mac][wasm] Work around MacOS 11.2 code page decommit failures MacOS 11.2 refuses to set "no access" permissions on memory that we previously used for JIT-compiled code. It is still unclear whether this is WAI on the part of the kernel. In the meantime, as a workaround, we use madvise(..., MADV_FREE_REUSABLE) instead of mprotect(..., NONE) when discarding code pages. This is inspired by what Chromium's gin platform does. Fixed: v8:11389 Change-Id: I866586932573b4253002436ae5eee4e0411c45fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679688 Commit-Queue: Jakob Kummerow <[email protected]> Commit-Queue: Michael Lippautz <[email protected]> Auto-Submit: Jakob Kummerow <[email protected]> Reviewed-by: Michael Lippautz <[email protected]> Cr-Commit-Position: refs/heads/master@{#72559} Backport-PR-URL: #38051 Co-authored-by: BoHong Li <[email protected]> Refs: v8/v8@0c8b6e4 Fixes: #37061 PR-URL: #37276 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ash Cripps <[email protected]>

m-chhapariya · 2022-01-05T14:35:09Z

I was also facing the similar issue with nodejs 15.3.0 on mac M1 chip

Starting the development server...

# Fatal error in , line 0
# Check failed: allocator->SetPermissions(reinterpret_cast<void*>(region.begin()), region.size(), PageAllocator::kNoAccess)

I tried installing node 17.2.0 and it is working fine.

Successful logs:

Compiled successfully!

You can now view my-react-app in the browser.

  Local:            http://localhost:3000
  On Your Network:  http://192.168.0.102:3000

Note that the development build is not optimized.
To create a production build, use npm run build.

dio · 2022-09-26T03:54:49Z

@matinzd or @targos if you don't mind, could you help to provide the gist.githubusercontent.com/targos/8ca8f7a0c76847f29f5658a93c30af1c/raw/adf420ca34e1e0a74c5a70ece059c3d0d2c5c043/crash.js, currently it is 404, attached to #37276? Wanted to learn about this :). Thanks!

andreialecu mentioned this issue Jan 25, 2021

Insiders on macOS ARM64: Extension Host crashes (SIGILL, EFAULT, EPIPE) microsoft/vscode#113410

Closed

lpinca added the v8 engine Issues and PRs related to the V8 dependency. label Jan 26, 2021

andreialecu mentioned this issue Jan 26, 2021

Apple silicon builds nodejs/build#2474

Closed

7 tasks

MarcoZehe mentioned this issue Jan 26, 2021

Crash on M1 Mac when calling many commands like login, link, etc. netlify/cli#1800

Closed

andreialecu mentioned this issue Jan 29, 2021

Support macOS Big Sur (10.16 / 11.0) #34043

Closed

aduh95 added arm Issues and PRs related to the ARM platform. macos Issues and PRs related to the macOS platform / OSX. labels Jan 29, 2021

andreialecu changed the title ~~WASM Native crash on 15.6 on latest macOS Beta: Fatal error Check failed: allocator->SetPermissions~~ macOS 11.2 RC3: Fatal error Check failed: allocator->SetPermissions Jan 29, 2021

This comment has been minimized.

Sign in to view

avocadowastaken mentioned this issue Feb 16, 2021

Prettier is trapping when evaluating a prisma file avocadowastaken/prettier-plugin-prisma#3

Closed

bayandin mentioned this issue Feb 18, 2021

[email protected] 1.1.1j Homebrew/homebrew-core#71329

Closed

phoenixy1 mentioned this issue Feb 25, 2021

npm ERR! command sh -c react-scripts start plaid/quickstart#177

Closed

icepy mentioned this issue Feb 26, 2021

无法使用 npm run build:h5 编译成H5页面 NervJS/taro#8760

Closed

bimusiek mentioned this issue Mar 5, 2021

[Apple M1] Electron crashes when using WASM electron/electron#28020

Closed

3 tasks

dev-seomoon mentioned this issue Apr 26, 2021

Fail to open development server dev-seomoon/pepple#1

Closed

purcell mentioned this issue Apr 28, 2021

n8n: fails to start on aarch64 NixOS/nixpkgs#119687

Closed

RunDevelopment mentioned this issue May 5, 2021

Ruby: Add heredoc literals PrismJS/prism#2885

Merged

smashah mentioned this issue Jul 6, 2021

yarn add @open-wa/wa-automate crash open-wa/wa-automate-nodejs#1847

Closed

woollybah mentioned this issue Nov 28, 2021

"Cannot allocate executable pages" on macOS/arm64 if GC_set_pages_executable(1) ivmai/bdwgc#394

Open

macOS 11.2: Fatal error Check failed: allocator->SetPermissions #37061

macOS 11.2: Fatal error Check failed: allocator->SetPermissions #37061

Comments

andreialecu commented Jan 25, 2021 • edited Loading

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior?

What do you see instead?

Additional information

andreialecu commented Jan 25, 2021 • edited Loading

GautierT commented Jan 26, 2021

andreialecu commented Jan 26, 2021

GautierT commented Jan 26, 2021

EriksRemess commented Jan 26, 2021 • edited Loading

MarcoZehe commented Jan 26, 2021

matinzd commented Jan 28, 2021 • edited Loading

panr commented Jan 29, 2021 • edited Loading

andreialecu commented Jan 29, 2021

panr commented Jan 29, 2021 • edited Loading

andreialecu commented Jan 29, 2021 • edited Loading

aduh95 commented Jan 29, 2021

andreialecu commented Jan 29, 2021

aduh95 commented Jan 29, 2021 • edited Loading

andreialecu commented Jan 29, 2021

aduh95 commented Jan 29, 2021

andreialecu commented Jan 29, 2021

matinzd commented Jan 29, 2021 • edited Loading

andreialecu commented Jan 29, 2021

aduh95 commented Jan 29, 2021 • edited Loading

andreialecu commented Jan 29, 2021

andreialecu commented Jan 29, 2021

andreialecu commented Feb 15, 2021 • edited Loading

carloskiki commented Feb 15, 2021 • edited Loading

goranmoomin commented Feb 15, 2021

andresilva-cc commented Feb 15, 2021

Virgil-N commented Feb 16, 2021

This comment has been minimized.

jakobkummerow commented Feb 16, 2021

aduh95 commented Feb 17, 2021 • edited Loading

etiennecossart commented Feb 18, 2021

karlhorky commented Feb 18, 2021

andresilva-cc commented Feb 18, 2021

m-chhapariya commented Jan 5, 2022

dio commented Sep 26, 2022

macOS 11.2: Fatal error `Check failed: allocator->SetPermissions` #37061

macOS 11.2: Fatal error `Check failed: allocator->SetPermissions` #37061

andreialecu commented Jan 25, 2021 •

edited

Loading

andreialecu commented Jan 25, 2021 •

edited

Loading

EriksRemess commented Jan 26, 2021 •

edited

Loading

matinzd commented Jan 28, 2021 •

edited

Loading

panr commented Jan 29, 2021 •

edited

Loading

panr commented Jan 29, 2021 •

edited

Loading

andreialecu commented Jan 29, 2021 •

edited

Loading

aduh95 commented Jan 29, 2021 •

edited

Loading

matinzd commented Jan 29, 2021 •

edited

Loading

aduh95 commented Jan 29, 2021 •

edited

Loading

andreialecu commented Feb 15, 2021 •

edited

Loading

carloskiki commented Feb 15, 2021 •

edited

Loading

aduh95 commented Feb 17, 2021 •

edited

Loading