Skip to content

malloc: *** error for object 0x10b5c62f8: pointer being freed was not allocated #13408

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

Closed
carllerche opened this issue Apr 8, 2014 · 2 comments

Comments

@carllerche
Copy link
Member

The following code when compiled on rust master then executed crashes with the error: "malloc: *** error for object 0x10b5c62f8: pointer being freed was not allocated"

struct Foo<T>;

fn foo<T>() -> ~Foo<T> {
  ~Foo
}

fn crash<T>(_: Option<T>, _: &Foo<T>) {
}

pub fn main() {
  crash(None, foo::<&str>());
}

My rustc info:

rustc 0.11-pre (2db9700 2014-04-07 08:56:34 -0700)
host: x86_64-apple-darwin

Edit: I guess my rustc is a day out of date. I am pulling latest master to double check.

@alexcrichton
Copy link
Member

I would suspect that de2567d fixes this, but I don't have a compiler on hand to verify

@thestinger
Copy link
Contributor

It's indeed fixed by de2567d.

bors added a commit to rust-lang-ci/rust that referenced this issue Oct 18, 2022
Bump chalk

There's a bug in current chalk that prevents us from properly supporting GATs, which is supposed to be fixed in v0.86. Note the following:
- v0.86 is only going to be released next Sunday so I'll keep this PR as draft until then.
- This doesn't compile without rust-lang/chalk#779, which I hope will be included in v0.86. I confirmed this compiles with it locally.

Two breaking changes from v0.84:
- `TypeFolder` has been split into `TypeFolder` and `FallibleTypeFolder` (rust-lang/chalk#772)
- `ProjectionTy::self_type_parameter()` has been removed (rust-lang/chalk#778)
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 24, 2024
Build quine-mc_cluskey with `opt-level=3` in dev builds

While doing some profiling I noticed that debug clippy running on the `clippy_lints` crate spends 35s out of 160s in one specific code path of `nonminimal_bool`, which seemed a bit excessive.

I've found that just enabling optimizations for quine-mc_cluskey (used by nonminimal_bool) cuts down the part that took 35s to 3s

While this doesn't really change anything for users, this helps dogfood a bit as it cuts off about half a minute of runtime (in some of my tests, at least).

Something similar was attempted in rust-lang#10576, however that involved compiling everything in release mode including clippy itself, whereas this only affects a single dependency that's compiled in parallel with something that takes longer so this should hopefully not have a negative impact in any case (and changing clippy doesn't require recompiling that dependency)

changelog: none
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants