Closed Th3G4mbl3r closed 4 years ago
Documenting a few things here, no official diagnosis yet:
ldd -r -v aws-crt-nodejs.node
linux-vdso.so.1 (0x00007ffc01bd9000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3b0aa30000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3b0a692000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3b0a48e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3b0a26f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3b09e7e000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3b0b251000)
undefined symbol: napi_coerce_to_bool (./aws-crt-nodejs.node) (snip)
Version information:
./aws-crt-nodejs.node:
librt.so.1 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/librt.so.1
libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2
ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
libpthread.so.0 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libpthread.so.0
libpthread.so.0 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libpthread.so.0
libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.25) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.17) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/librt.so.1:
(snip)
Of particular interest is the GLIBC_2.25 line. The lambda sandbox's glibc was not that high as of a few years ago, unknown what it is presently, but this may indicate that the native parts of the crt are built against a later glibc than what lambda supports.
This blog post
https://cloudbriefly.com/post/exploring-the-aws-lambda-execution-environment/
seems to indicate that one of the images used as a lambda sandbox has glibc 2.17, while the other uses 2.26. Based on this documentation
https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html
it appears that all versions of node are running on AL2 which should have 2.26, so this may be a dead end.
This blog post
https://cloudbriefly.com/post/exploring-the-aws-lambda-execution-environment/
seems to indicate that one of the images used as a lambda sandbox has glibc 2.17, while the other uses 2.26. Based on this documentation
https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html
it appears that all versions of node are running on AL2 which should have 2.26, so this may be a dead end.
so what does this mean? Does it mean that the new version of the sdk cannot be used in lambda functions?
Not able to conclude anything yet. I'm just documenting what I've looked into so far. If you are able to open an internal ticket that would be ideal.
Not able to conclude anything yet. I'm just documenting what I've looked into so far. If you are able to open an internal ticket that would be ideal.
Hi Bret,
Thanks for the quick response. I've reached out to you internally as well on the internal ticket process. In the meantime i will leave this open in case someone else faces the same issue.
thanks & regards, rohit
based on feedback on internal AWS ticket, realized that instead of using the "import" statement approach, using "require" works. So i will close this issue for now. The existing sample codes should be modified to reflect the same as well.
Confirm by changing [ ] to [x] below to ensure that it's a bug:
Describe the bug AWS IoT SDK depends on aws-crt. As soon as i try to import any object from aws-crt the lambda function with Runtime.UserCodeSyntaxError.
SDK version number
"aws-crt": "^1.1.5", "aws-iot-device-sdk-v2": "^1.2.1"
Platform/OS/Hardware/Device MacOS Catalina 10.15.5 and node 10.21.0
To Reproduce (observed behavior) Steps to reproduce the behavior (please share code)
Expected behavior Lambda function should be able to load completely and start excuting.
Logs/output