-
Notifications
You must be signed in to change notification settings - Fork 231
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
Segmentation Fault on ARM device #75
Comments
run in gdb and grab a backtrace? |
Hey @gavofyork , actually the excerpt above was run in gdb already, although I had only enabled it for libweb3core, libethereum and webthree, but none of the dependencies |
What is the result of asking for a backtrace? Type |
here's the backtrace:
|
So that is SUPER early in initialization. Before main() runs, even. |
Yep - the m_params member's constructor is being called implicitly, and I would imagine it's trying to do stuff just way, way too early. Let's find where this singleton or global variable is. |
Line 53 in Common.cpp: static Secp256k1PP s_secp256k1pp; |
Was ETH_HAVE_SECP256K1 that symbol which you found mis-placed #defines for, Anthony? |
Is it #define on or off for your build? Which code-path are we following? The one into Secp256k1PP, it looks like? |
No Bob, it wasn't that #define |
that being said I didn't build SECP256K1 as it didn't seem required, maybe I need the library in my /lib anyway? |
No, doesn't look that way. |
awesome :) |
A lot of this "pre-main" stuff is very device-specific and undefined. Best practice is not to use global variables. In this case, not because of the scope of visibility, because of the loss of control of execution time for the constructor. Surprise, surprise. Global variables are bad. Again :-) |
This got fixed by @gavofyork. Please could you close the ticket, @anthony-cros? Thanks! |
I cross-compiled
eth
for ARM and tried running it on a tizen phone. I'm getting a seg fault about 2 seconds after starting the program (no logs). I went ahead and re-compiled with debug on, and here was the result (duplicate lines removed):The sources for CryptoPP definitely contain a ./cryptlib.cpp and the logs of compilation don't seem to show anything unusual about this file: https://gist.github.com/anthony-cros/1540ff3393b0926ccce7
The text was updated successfully, but these errors were encountered: