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

Breakage due to changing jemalloc symbol names #31780

Closed
brson opened this issue Feb 20, 2016 · 6 comments
Closed

Breakage due to changing jemalloc symbol names #31780

brson opened this issue Feb 20, 2016 · 6 comments
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. relnotes Marks issues that should be documented in the release notes of the next release.

Comments

@brson
Copy link
Contributor

brson commented Feb 20, 2016

We recently unprefixed the jemalloc symbols, which causes breakage when you link to them.

@brson brson added A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. labels Feb 20, 2016
@bluss
Copy link
Member

bluss commented Feb 21, 2016

it's expected (the change is tagged relnotes). It also affects people that used JE_MALLOC_CONF to tune jemalloc options.

@nagisa
Copy link
Member

nagisa commented Feb 22, 2016

Presence of certain symbols (used by rust runtime/standard library) shouldn’t be covered by our stability policy IMO, because otherwise I could just link_name to backtrace_print and we’re are never getting rid of libbacktrace in every rust binary by default, for example.

EDIT. pretty much what @SimonSapin said.
EDIT 2. if not clear, my point, and opinion, is: this bug is inactionable.

@nikomatsakis
Copy link
Contributor

I'm inclined to think we can close this, but I'm curious to hear @brson's and @alexcrichton's opinion. One thing we could do is to re-export the old names, but I feel like we made no promise to export those particular names. It's clear that the breakage resulted from relying on impl details, but do we have a plan how one could gain access to Rust allocator in a stable-ish way?

@alexcrichton
Copy link
Member

My feeling here is that we shouldn't provide any guarantees about these sorts of symbols. If we want to provide access to jemalloc internals we should do so through the alloc_jemalloc crate in an unstable API, not through various symbol names that tie our hands even more than before.

We got clear perf wins from unprefixing jemalloc symbols on Linux, I'd personally prefer to not lose that.

@SimonSapin
Copy link
Contributor

FWIW, we ended up with a build script that parses rustc -vV and makes the crate link to different symbols based on the Rust version number and commit date: https://github.com/servo/heapsize/blob/98d4019e/build.rs

I don’t think the symbol change should be reverted, so this issue can probably be closed. A better way forward is to properly expose the functionality so we don’t need this extern fn hack at all: #32075

@nikomatsakis nikomatsakis added the relnotes Marks issues that should be documented in the release notes of the next release. label Apr 7, 2016
@nikomatsakis
Copy link
Contributor

I am going to close this. I'll tag with relnotes I guess in case we want to announce the change, but I think this is a clear case of depending on unstable ABIs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. relnotes Marks issues that should be documented in the release notes of the next release.
Projects
None yet
Development

No branches or pull requests

6 participants