require('gcloud') crashing on Mac #681
Assignees
Comments
|
I think this might be related to #425. Can you take a look ? |
|
@javorosas can you check if the following works: $ npm install sse4_crc32
...
$ node -pe "require('sse4_crc32')"
{ isHardwareCrcSupported: [Function: isHardwareCrcSupported],
calculateInSoftware: [Function: swCrc32c],
calculateOnHardware: [Function: hwCrc32c],
CRC32: [Function: Crc32C],
calculate: [Function: hwCrc32c] } |
|
Running Output: Sorry I don't really know what I'm supposed to do with |
|
Thanks for verifying. The rest of text is the output I see on my Mac. Your output confirms that the problem you're running into is indeed related to #425 and the $ sysctl -n machdep.cpu.brand_stringOn my machine it outputs: 'Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz'. @anandsuresh FYI. |
|
I'm running a pretty shitty hardware actually. Mid 2007. Output: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz |
|
Hey all. My first guess is that my CPU detection code might not be airtight on some platforms, esp. older ones. Can you all please run the following commands on your boxes and paste the output here. It would help debug this issue. $ sysctl -n machdep.cpu.brand_string
Intel(R) Core(TM) i7-4650U CPU @ 1.70GHz
$ uname -a
Darwin AnandSuresh-23981.local 13.4.0 Darwin Kernel Version 13.4.0: Wed Mar 18 16:20:14 PDT 2015; root:xnu-2422.115.14~1/RELEASE_X86_64 x86_64
$ node -pe "require('sse4_crc32').isHardwareCrcSupported()"
true
$ |
|
|
Did you recently update node.js on your machine? If so try running |
|
I installed node using nvm and changed the node version when it first crashed. I rebuilt the modules every time I changed the version, though. This is my output for |
|
from the errors this deff looks like an assembly prob. Try to compile and running that portion on your own and see if it blows up. I'll try to research what instruction it doesn't like, but not easy without having a machine with your cpu. #include <iostream>
using namespace std;
void cpuid(uint32_t op, uint32_t reg[4]) {
#if defined(__x86_64__)
__asm__ volatile(
"pushq %%rbx \n\t"
"cpuid \n\t"
"movl %%ebx, %1 \n\t"
"popq %%rbx \n\t"
: "=a"(reg[0]), "=r"(reg[1]), "=c"(reg[2]), "=d"(reg[3])
: "a"(op)
: "cc");
#elif defined(_WIN64) || defined(_WIN32)
#include <intrin.h>
__cpuid((int *)reg, 1);
#else
__asm__ volatile(
"pushl %%ebx \n\t"
"cpuid \n\t"
"movl %%ebx, %1 \n\t"
"popl %%ebx \n\t"
: "=a"(reg[0]), "=r"(reg[1]), "=c"(reg[2]), "=d"(reg[3])
: "a"(op)
: "cc");
#endif
}
int main(int argc, char *argv[]) {
uint32_t reg[4];
cpuid(1, reg);
printf(((reg[2] >> 20) & 1) == 1 ? "yes\n" : "no\n");
}compileg++ -o cpuid cpuid.cpp |
|
I compiled and ran the code. The output is: |
|
not an assembly issue then. reviewing the cpp code now |
|
@javorosas @abelino The output seems to be expected. The Intel T7300 processor does not have the SSE 4.2 chipset and consequently we get a negative output. What baffles me is the fact that the library isn't using the software fallback. Based on a previous message posted by @javorosas (pasted below for reference), it seems that the library is attempting to use H/w CRC even though the platform doesn't support it. The |
|
@javorosas Can you confirm that the output I pasted in the last message was indeed something that you saw at your end or did I misinterpret your message? |
|
Yea I would like to know the same. From my understanding, I don't think he got that far. |
|
No, I never saw that in the terminal. |
|
ok so this is deff a compile time error, but at least we know its not an assembly code issue. |
|
@javorosas Do you have |
|
@anandsuresh No |
|
@javorosas Can you also confirm that you can run an |
|
do you think the functions mm_crc32* can be causing the prob on non sse4 systems? |
|
I installed node-gyp globally with @anandsuresh |
|
@javorosas I'm guessing running |
|
@anandsuresh yes |
|
@abelino The mm_crc32* functions are only part of the hardware function. So that function should not be called on @javorosas' platform since it doesn't support H/W CRC. Seems to be some weird linkage issue where the |
|
@javorosas Can you paste the output of |
|
Also @javorosas , |
|
@anandsuresh I don't even think its getting past NODE_MODULE(sse4_crc32, init) since we are exporting the hwCrc, and since hwCrc32c is compiled, the following lines might be the prob at compile time 188, 195-197 |
|
I changed |
|
any particular reason why we aren't using the something like: #ifdef __SSE4_2__
#include <smmintrin.h>
#endif
#ifdef __SSE4_2__
uint32_t hwCrc32c(uint32_t initialCrc, const char *buf, size_t len) {
//stuff
}
NAN_METHOD(hwCrc) {
//stuff
}
#endif
#ifdef __SSE4_2__
NODE_SET_METHOD(exports, "hwCrc", hwCrc);
#endif |
Are you guys sure the xcode warnings I'm getting don't have anything to do with this issue? |
|
@abelino @javorosas From the log pasted, we can see that the initialization is running just fine. The Also, I get no xcode warnings on my system. |
|
@anandsuresh you are 100% correct on that. A very curious case here |
|
@javorosas here comes another test :D If this compiles and runs properly, then its deff an issue with the js bindings. cd /tmp
git clone [email protected]:abelino/sse4_crc32.git
cd sse4_crc32
git checkout cpptest
cd test
make |
|
@javorosas @abelino I apologize for my last test. I had the log lines in the wrong place. I've updated the branch. Please do a |
|
@abelino :D yaay! another test No errors apparently |
|
@javorosas wow ok that totally proves the c++ code is good. Now let us know what you get from the test on branch anand-crc-test. |
|
|
@javorosas just to be 100% did you do git pull --rebase on the anand-crc-test |
|
@javorosas If you did do a |
|
@abelino yes, I'm actually removing the whole folder every time I'm making the test |
|
@javorosas Can you add a printf to line 317 in |
|
I inserted the following logs: Around line 98: Around line 316: These are the last lines in the output when running |
|
that is very interesting. The initCrcTable function ran fine when you ran the cpptest earlier. Something funky is going on. |
|
The good news: Now we have more information and know where to start our debugging. Since you were able to run the initCrcTable function without errors using @abelino's code, it stands to reason that it should work in this scenario too. But as we can see, our assumption is being proven wrong! Seems that we will need more information:
|
|
I have a feeling that you've recently upgraded to the latest/greatest Darwin kernel, and have received the corresponding Clang compiler, which might be responsible for this. |
|
@abelino I might consider adding |
|
|
@javorosas I'm running clang 6.0 on kernel 13.4 and face no issues. Can you try this on a different OS platform, like a lower kernel version? I'm trying to get my hands on an updated kernel to test at my end as well. |
|
I'm not able to try it in a different kernel version, since it's the computer from my job. But I can keep executing tests if it helps. |
|
@javorosas locally can you replace the type on line 97 from |
|
We have quite a few of these issues popping up here that are actually coming from https://github.com/Voxer/sse4_crc32. I think since it's been almost 2 months since a reply here, this has been resolved. If not, it will probably be easier to open this up over at their repo for better, quicker help: https://github.com/Voxer/sse4_crc32. |
4 tasks
sofisl
pushed a commit
that referenced
this issue
Oct 11, 2022
* chore(main): release 5.0.2 * 🦉 Updates from OwlBot post-processor See https://github.com/googleapis/repo-automation-bots/blob/main/packages/owl-bot/README.md Co-authored-by: release-please[bot] <55107282+release-please[bot]@users.noreply.github.com> Co-authored-by: Owl Bot <gcf-owl-bot[bot]@users.noreply.github.com>
sofisl
pushed a commit
that referenced
this issue
Oct 13, 2022
* chore(main): release 5.0.2 * 🦉 Updates from OwlBot post-processor See https://github.com/googleapis/repo-automation-bots/blob/main/packages/owl-bot/README.md Co-authored-by: release-please[bot] <55107282+release-please[bot]@users.noreply.github.com> Co-authored-by: Owl Bot <gcf-owl-bot[bot]@users.noreply.github.com>
4 tasks
sofisl
pushed a commit
that referenced
this issue
Nov 11, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
My old computer and my server instance both run Ubuntu and I never had any problem at all. Recently I'm using a Mac to code and have not been able to make this module work.
How to reproduce
I started a new project to isolate the issue to a minimum. This is the content of my
server.js:I'm using:
Reproducing:
node server.json the terminalWhat I suspect
When I'm installing the npm module:
I get the following output:
I've googled those xcode-related warnings but haven't found anything relevant. I don't know if it's related with the issue, though.
Any clues?
The text was updated successfully, but these errors were encountered: