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

(signal: 11, SIGSEGV: invalid memory reference) x86_64-unknown-linux-musl #84576

Open
sabirmgd opened this issue Apr 26, 2021 · 3 comments
Open
Labels
C-bug Category: This is a bug. O-musl Target: The musl libc T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@sabirmgd
Copy link

sabirmgd commented Apr 26, 2021

I do my development in windows but test and package the application in alpine, I have issues when creating any type of https client, it particularly fails when the code tries to create an https client of any sort, for example (s3 rusoto client, elasticsearch client)

I created a small project to actually re-produce this issue:
I'm using docker on alpine, here is my environment:


FROM alpine:3.13.4

# <channel>[-<date>][-<host>]
# <channel>       = stable|beta|nightly|<major.minor>|<major.minor.patch>
# <date>          = YYYY-MM-DD
# <host>          = <target-triple>
ARG TOOLCHAIN_CHANNEL=nightly
ARG TOOLCHAIN_DATE=2021-03-25
ARG TOOLCHAIN_HOST=x86_64-unknown-linux-musl

ENV RUSTUP_HOME=/usr/local/rustup \
    CARGO_HOME=/usr/local/cargo \
    PATH=/usr/local/cargo/bin:$PATH

RUN apk upgrade; \
    apk update; \ 
    apk add util-linux pciutils usbutils coreutils binutils findutils grep \
            curl bash openssl libressl-dev gcc build-base ca-certificates; \
    curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y -v \
      --no-modify-path \
      --default-toolchain ${TOOLCHAIN_CHANNEL}-${TOOLCHAIN_DATE}-${TOOLCHAIN_HOST} \
      --profile minimal; \
    chmod -R a+w $RUSTUP_HOME $CARGO_HOME; \
    rustup --version; \
    cargo --version; \
    rustc --version; \
    rustup component add llvm-tools-preview; \
    rustup component add clippy; \
    cargo install grcov --vers 0.6.1;

as you can see, I locked it down to a specific nightly version ( but you can feel free to change it to any, I tried many versions.

main.rs:

static DEFAULT_ELASTIC_SEARCH_ADDRESS: &str =
    "https://myaddress.com";

use elasticsearch::http::transport::SingleNodeConnectionPool;
use elasticsearch::http::transport::TransportBuilder;
use elasticsearch::http::Url;
use elasticsearch::Error;
use elasticsearch::{auth::Credentials, Elasticsearch};

fn main() {
    let _client = create_client();
}


#[allow(dead_code)]
pub fn create_client() -> Result<Elasticsearch, Error> {
    let username = "user".to_string();
    let password = "password".to_string();
    let credentials = Credentials::Basic(username, password);
    let endpoint = DEFAULT_ELASTIC_SEARCH_ADDRESS.to_string();
    let url = Url::parse(&endpoint)?;
    let conn_pool = SingleNodeConnectionPool::new(url);
    let transport = TransportBuilder::new(conn_pool).auth(credentials).build()?;
    Ok(Elasticsearch::new(transport))
}


#[test]
fn query_studies_within_files() {
    let _client = create_client();
}

and the cargo.toml file

[package]
name = "test_http"
version = "0.1.0"
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
dotenv = "0.15.0"
elasticsearch = "7.12.0-alpha.1"
rusoto_s3 = "0.46.0"
rusoto_core = "0.46.0"
rusoto_credential = "0.46.0"
serde = { version = "1.0.125", features = ["derive"] }
serde_yaml = "0.8.17"
serde_json = "1.0.64"
json = "0.12"

I'm not really sure what could possibly be the reason is, it something to do with https because if I remove the https from the url static DEFAULT_ELASTIC_SEARCH_ADDRESS: &str = "https://myaddress.com"; to be myaddress.com, the test succeeds. however, of course, it would not get a proper client.

I just excepted this simple unit test that will create a client to succeed

Instead, this happened: I get (signal: 11, SIGSEGV: invalid memory reference) x86_64-unknown-linux-musl

Meta

rustc --version --verbose:

rustc --version --verbose
rustc 1.53.0-nightly (07e0e2ec2 2021-03-24)
binary: rustc
commit-hash: 07e0e2ec268c140e607e1ac7f49f145612d0f597
commit-date: 2021-03-24
host: x86_64-unknown-linux-musl
release: 1.53.0-nightly
LLVM version: 12.0.0
Backtrace

<backtrace>

@sabirmgd sabirmgd added the C-bug Category: This is a bug. label Apr 26, 2021
@nagisa
Copy link
Member

nagisa commented Apr 26, 2021

You probably end up linking two distinct libcs into your binary. One static from self-contained rust build and other dynamic through dynamic dependencies on native C libraries (e.g. openssl).

In which case this would be a duplicate of #82193

@imuli
Copy link

imuli commented May 9, 2021

I'm running into something like this (which may or may not be the same bug). As a minimal example:

hello.rs:

fn main() {
    println!("Hello, World!");
}
$ rustc --target x86_64-unknown-linux-musl hello.rs && ./hello
Segmentation fault (core dumped)
$ rustc -C relocation-model=static --target x86_64-unknown-linux-musl hello.rs && ./hello
Hello, World!

This is with current nightly on linux.

rustc 1.54.0-nightly (881c1ac40 2021-05-08)
binary: rustc
commit-hash: 881c1ac408d93bb7adaa3a51dabab9266e82eee8
commit-date: 2021-05-08
host: x86_64-unknown-linux-gnu
release: 1.54.0-nightly
LLVM version: 12.0.0

@mati865
Copy link
Contributor

mati865 commented May 9, 2021

@imuli looks like opposite issue from #73661

@ChrisDenton ChrisDenton added the needs-triage-legacy Old issue that were never triaged. Remove this label once the issue has been sufficiently triaged. label Jul 16, 2023
@jieyouxu jieyouxu added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. O-musl Target: The musl libc and removed needs-triage-legacy Old issue that were never triaged. Remove this label once the issue has been sufficiently triaged. labels Feb 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. O-musl Target: The musl libc T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants