SIGSEGV while initializing tcnative #681
Comments
|
Originally reported at Alluxio/alluxio#12704 (comment) |
|
Yeah it should use the apr version which is statically compiled into it. Can you check what happens when you remove apr from the system itself ? |
|
I've removed the following packages: |
|
Is it possible to share a docker image that reproduce it ?
… Am 22.11.2021 um 12:12 schrieb Martin Grigorov ***@***.***>:
I've removed the following packages: libapr1-dev libaprutil1-dev libsctp-dev{u} libsctp1{u} libsvn-dev{a} but nothing changed :-/
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Do you have ARM64 hardware to run the Docker image ? Emulating with QEMU would be slow. Otherwise I could give you access to my VM ? Please send me an email to mgrigorov @ apache org if you prefer the VM approach! |
|
I have a m1 so I guess that should do it ? |
|
Hopefully! |
|
|
Without Docker the steps are:
|
|
If I add |
|
I will check most likely tomorrow.. |
|
I think I've found the problem! but down in the |
|
interesting... that said I think it should not segfault |
|
I am not sure why it segfaults but hs_err*.txt says the problem is at: |
|
I've just unzipped and exported The test passed ! Without |
|
@martin-g so you say you didn't need to change anything ? All you did was unzip and sett |
|
Right! I am debugging the test locally on x86_64 and all seems fine with the logic. |
|
If you need to enable logging for the test you could add |
|
I am trying to build Netty locally with some extra logging but it fails at: https://repo.maven.apache.org/maven2/io/netty/netty-tcnative/2.0.46.Final/ contains only the Update: I've hacked it by changing |
|
@martin-g use |
|
I've found the issue! It found some other library in a dependency jar. @normanmaurer Do you think using ClassLoader#getResources(String) at |
|
@martin-g not sure I follow what you propose.. Can you show via a PR ? |
|
I will prepare a PR! |
|
got it... I guess we might just throw if we find multiple as it is hard to know which one is correct if shading is used. |
Fixes netty/netty-tcnative#681 Throw an exception when there are multiple netty-tcnative-** libraries with the same path in the classpath
|
I've reported the problem to Apache Ratis: https://issues.apache.org/jira/browse/RATIS-1443 |
Throw an exception when there are multiple netty-tcnative-** libraries with the same path in the classpath Motivation: Currently Netty loads the first resource in the classpath with a given name. It seems there are [libraries](netty/netty-tcnative#681 (comment)) which provide Netty's native libraries themselves. Modification: From now on Netty will look for all resources with the given name and throw an exception if there are more than one. The user application needs to make sure that there is at most one provider of Netty's native libraties (netty-tcnative-**) Result: Fixes netty/netty-tcnative#681.
Throw an exception when there are multiple netty-tcnative-** libraries with the same path in the classpath Motivation: Currently Netty loads the first resource in the classpath with a given name. It seems there are [libraries](netty/netty-tcnative#681 (comment)) which provide Netty's native libraries themselves. Modification: From now on Netty will look for all resources with the given name and throw an exception if there are more than one. The user application needs to make sure that there is at most one provider of Netty's native libraties (netty-tcnative-**) Result: Fixes netty/netty-tcnative#681.
…#11856) Throw an exception when there are multiple netty-tcnative-** libraries with the same path in the classpath Motivation: Currently Netty loads the first resource in the classpath with a given name. It seems there are [libraries](netty/netty-tcnative#681 (comment)) which provide Netty's native libraries themselves. Modification: From now on Netty will look for all resources with the given name and throw an exception if there are more than one. The user application needs to make sure that there is at most one provider of Netty's native libraties (netty-tcnative-**) Result: Fixes netty/netty-tcnative#681.
…#11856) Throw an exception when there are multiple netty-tcnative-** libraries with the same path in the classpath Motivation: Currently Netty loads the first resource in the classpath with a given name. It seems there are [libraries](netty/netty-tcnative#681 (comment)) which provide Netty's native libraries themselves. Modification: From now on Netty will look for all resources with the given name and throw an exception if there are more than one. The user application needs to make sure that there is at most one provider of Netty's native libraties (netty-tcnative-**) Result: Fixes netty/netty-tcnative#681.
…#11856) Throw an exception when there are multiple netty-tcnative-** libraries with the same path in the classpath Motivation: Currently Netty loads the first resource in the classpath with a given name. It seems there are [libraries](netty/netty-tcnative#681 (comment)) which provide Netty's native libraries themselves. Modification: From now on Netty will look for all resources with the given name and throw an exception if there are more than one. The user application needs to make sure that there is at most one provider of Netty's native libraties (netty-tcnative-**) Result: Fixes netty/netty-tcnative#681.
Hi,
Netty: 4.1.70
Netty tcnative: 2.0.46
Grpc: 1.42.1
I face a strange issue while trying to run a simple Grpc service on Ubuntu 20.04.3 ARM64:
The following stack trace leads to SIGSEGV:
The application uses boringssl-static (see the attached mvn-dependency-tree.txt). According to https://netty.io/wiki/forked-tomcat-native.html when boringssl-static is being used then APR is not needed but the core dump says:
Apr is installed on the system:
Please let me know if I can provide more information!
mvn-dependency-tree.txt
hs_err_pid148138.log
The text was updated successfully, but these errors were encountered: