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

Linking failure in asm? #8

Open
milesj opened this issue Mar 20, 2020 · 16 comments
Open

Linking failure in asm? #8

milesj opened this issue Mar 20, 2020 · 16 comments

Comments

@milesj
Copy link

milesj commented Mar 20, 2020

@vadimdemedes After upgrading to Node 12 (12.16.1), this warning pops up all the time in my cli, usually when running tests (I'm using ink). This doesn't happen in Node 10.

(node:64225) V8: /project/node_modules/yoga-layout-prebuilt/yoga-layout/build/Release/nbind.js:1781 Linking failure in asm.js: Unexpected stdlib member
@vadimdemedes
Copy link
Owner

Hm I don't see that error myself. Would you be able to provide a minimal reproduction?

@milesj
Copy link
Author

milesj commented Jul 5, 2020

I see it all the time running boost tests https://github.com/milesj/boost

@milesj
Copy link
Author

milesj commented Jul 5, 2020

An example screenshot
Screen Shot 2020-07-05 at 12 04 00

@MirKml
Copy link

MirKml commented Jul 24, 2020

same for me, because of react-pdf dependency - diegomura/react-pdf#603

@vadimdemedes
Copy link
Owner

Hey @milesj, I've came to a conclusion that it has something to do with the way your testing (or project) is set up. Here's why.

Node.js v12 support

Ink's own tests run in both 10.x and 12.x versions of Node.js and no such warning is logged to the console. Also, while it's true that yoga-layout-prebuilt can't run build.sh script in Node.js v12.x, that doesn't mean that the prebuilt version of Yoga generated via Node.js v10.x can't be used with Node.js v12.x.

To double check this I pushed https://github.com/vadimdemedes/yoga-layout-prebuilt/tree/node12 branch with support for building this project in Node.js v12.x and the resulting code still caused the same warning.

Jest?

I noticed that both boost and react-pdf projects use Jest for testing, so I suspected maybe that's the problem. It turned out that it's not. I set up Jest + Ink tests in vadimdemedes/ink-testing-library#13 and no warning was logged either.

The root cause

Then, I started gradually removing code from packages/cli/tests/Program.test.tsx and found that this warning doesn't appear if I remove all imports of ../src. Since ink is still being imported (and so is yoga-layout-prebuilt by consequence), I guess it points to something else. This is the code of Program.test.tsx I had that still logs the error:

import React, { useContext } from 'react';
import { Box, Text } from 'ink';
import Command from '../src/Command';

class BoostCommand extends Command {
  static description = 'Description';

  static path = 'boost';

  static allowUnknownOptions = true;

  static allowVariadicParams = true;

  run() {
    return Promise.resolve();
  }
}

test('x', () => {
  expect(true).toEqual(true)
})

After ../src/Command is removed, no warning is logged.

import React, { useContext } from 'react';
import { Box, Text } from 'ink';
- import Command from '../src/Command';

Then comes the weird part, which made me think it could be something in Jest or its setup. I copied the same code with src import and saved it into packages/cli/check.js, so that I can run the same code, but without Jest:

const React = require('react');
const { Box, Text } = require('ink');
const Command = require('./lib/Command').default

class BoostCommand extends Command {
  static description = 'Description';

  static path = 'boost';

  static allowUnknownOptions = true;

  static allowVariadicParams = true;

  run() {
    return Promise.resolve();
  }
}

Now no error, even though Command is imported again. I don't know where to go from this point on to be honest, so I would love your help in figuring out a minimal reproducible example of this issue. Ideally it should be a "raw" script, without Jest or any other testing framework or wrapper.

@milesj
Copy link
Author

milesj commented Jul 26, 2020

Oh wow, that's some nice detective work, thank you. I'll see what I can come up with.

@milesj
Copy link
Author

milesj commented Nov 29, 2020

So I'm finally looking into this a bit and was able to reduce the Command class down to this, which still caused the warning.

import React from 'react';
import { Help } from './components/Help';

export default class Command {
  renderHelp(): React.ReactElement {
    const metadata = this.getMetadata();

    return (
      <Help
        categories={metadata.categories}
        config={metadata}
        header={metadata.path}
        options={metadata.options}
        params={metadata.params}
      />
    );
  }
}

Removing the Help import stops the warning. With or without the React import didn't change anything. Digging further, but nothing seems odd yet. Here's the component itself: https://github.com/milesj/boost/blob/master/packages/cli/src/components/Help.tsx

@milesj
Copy link
Author

milesj commented Nov 29, 2020

Ok so I reduced Help to the following and the warning still persisted.

import React from 'react';
import { Box } from 'ink';

export interface HelpProps {}

export class Help extends React.Component<HelpProps> {
  render() {
    return <Box flexDirection="column"></Box>;
  }
}

Even tried a function component and the problem persists.

import React from 'react';

export function Help() {
  return <Box flexDirection="column"></Box>;
}

However, removing the ink import causes the warning to go away. Which is super odd.

import React from 'react';
import { Box } from 'ink';

export function Help() {
  return <Box flexDirection="column"></Box>;
}

Here's the PR I'm debugging with milesj/boost#125

@milesj
Copy link
Author

milesj commented Nov 29, 2020

Also found out that this doesn't trigger the warning:

import { Text } from 'ink';

But this does:

import { Box } from 'ink';

I think it may be because the built files are using getters.

var Box_1 = require("./components/Box");
Object.defineProperty(exports, "Box", { enumerable: true, get: function () { return Box_1.default; } });
var Text_1 = require("./components/Text");
Object.defineProperty(exports, "Text", { enumerable: true, get: function () { return Text_1.default; } });

@milesj
Copy link
Author

milesj commented Nov 29, 2020

Warning stills shows on Node 14, but looks like we can trace it now. This is the output.

 ✘  ~/Projects/boost   debug-yoga  node --trace-warnings ./node_modules/.bin/jest packages/cli/tests/Command2.test.tsx
(node:47075) V8: /Users/milesj/Projects/boost/node_modules/yoga-layout-prebuilt/yoga-layout/build/Release/nbind.js:1781 Linking failure in asm.js: Unexpected stdlib member
    at /Users/milesj/Projects/boost/node_modules/yoga-layout-prebuilt/yoga-layout/build/Release/nbind.js:9750:4
    at Object.<anonymous> (/Users/milesj/Projects/boost/node_modules/yoga-layout-prebuilt/yoga-layout/dist/entry-browser.js:21:1)
    at Runtime._execModule (/Users/milesj/Projects/boost/node_modules/jest-runtime/build/index.js:1299:24)
    at Runtime._loadModule (/Users/milesj/Projects/boost/node_modules/jest-runtime/build/index.js:898:12)
    at Runtime.requireModule (/Users/milesj/Projects/boost/node_modules/jest-runtime/build/index.js:746:10)
    at Runtime.requireModuleOrMock (/Users/milesj/Projects/boost/node_modules/jest-runtime/build/index.js:919:21)
    at Object.<anonymous> (/Users/milesj/Projects/boost/node_modules/ink/src/reconciler.ts:6:1)
    at Runtime._execModule (/Users/milesj/Projects/boost/node_modules/jest-runtime/build/index.js:1299:24)
    at Runtime._loadModule (/Users/milesj/Projects/boost/node_modules/jest-runtime/build/index.js:898:12)
    at Runtime.requireModule (/Users/milesj/Projects/boost/node_modules/jest-runtime/build/index.js:746:10)

And the jest-runtime to trace: https://gist.github.com/milesj/5fa74043d405c56826750bbe3721b932 Nothing stands out so far in this file, but I can verify that it's requiring the actual module and not a mock.

@milesj
Copy link
Author

milesj commented Nov 29, 2020

Seems to be no progress on this issue, so I'm at a dead end here. facebook/yoga#898

Saw this notice, but is yoga being built for node and not the browser? https://github.com/facebook/yoga#build-platforms

@milesj
Copy link
Author

milesj commented Nov 29, 2020

Just stumbled upon this too: yarnpkg/berry#2176 Seems to be more widespread than initially thought.

@arcanis
Copy link

arcanis commented Nov 29, 2020

Our problem in yarnpkg/berry#2176 is different; the Yoga build includes an annoying listener on uncaughtException, which causes problems when it gets instantiated multiple times (usually shouldn't, but we have some particular setups where it might happen). As a result, Node eventually prints (incorrect) warnings about Possible EventEmitter memory leak detected.

@tarunama
Copy link

👍

@milesj milesj changed the title Node 12 support? Linking failure in asm? Jan 22, 2021
@AriPerkkio
Copy link

Thanks for raising this issue @milesj. I've been seeing these errors as well but just tried to avoid looking into this.

(node:2836) V8: /home/runner/work/eslint-remote-tester/eslint-remote-tester/node_modules/yoga-layout-prebuilt/yoga-layout/build/Release/nbind.js:1781 Linking failure in asm.js: Unexpected stdlib member

All my CI runs contain this error: https://github.com/AriPerkkio/eslint-remote-tester/runs/1723287334?check_suite_focus=true

I recently tried esbuild for bundling an application using Ink. These errors started appearing outside tests as well - the error message is a bit different though. This example from ink is enough to reproduce this.

$ node dist
(node:7363) V8: /home/<removed>/esbuild-ink-repro/dist/index.js:30453 Invalid asm.js: Type mismatch in assignment
(Use `node --trace-warnings ...` to show where the warning was created)
Use arrow keys to move the face. Press “q” to exit.

 ^_^

@ghost
Copy link

ghost commented Oct 5, 2022

facebook/yoga#898 (comment) This issue was closed and passed to this repo.

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

6 participants