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.

Sign up for GitHub

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

Jump to bottom

Memory leak when calling span_fatal from trans #2272

Closed
marijnh opened this issue Apr 23, 2012 · 3 comments
Closed

Memory leak when calling span_fatal from trans #2272

marijnh opened this issue Apr 23, 2012 · 3 comments
Assignees
@brson
Milestone
0.3

Comments

@marijnh
Copy link
Contributor

marijnh commented Apr 23, 2012

Commit 68f8812 introduces a check that can't easily be done in any pass before trans. The test case in that commit is disabled because currently it will cause a memory leak (12 objects lost) when compiled.
@brson
Copy link
Contributor

brson commented Apr 23, 2012

This test succeeds when I modify type_needs_unwind_cleanup to always return true. There is some type here that gets cleaned up correctly via landing pads, but can't be found by the box annihilator.

@ghost ghost assigned brson Apr 23, 2012
@brson
Copy link
Contributor

brson commented Apr 24, 2012

type_needs_unwind_cleanup is completely broken I believe. Oops.

catamorphism added a commit that referenced this issue Apr 24, 2012
@catamorphism
Allow classes to be cast to ifaces that are in the same crate
f764128 
I had to xfail one existing test case (class-implements-int) because,
I think, of the same bug described in #2272.
@catamorphism
Copy link
Contributor

I think I just got bit by the same bug -- see the above-referenced commit. In my case I was calling span_fatal from typeck. The fix @brson suggested fixed it as well, but rather than checking in that fix, I just xfailed the test (class-implements-int), since @brson said he was going to work on it tomorrow.

@brson brson closed this as completed in e7dbf42 Apr 24, 2012
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
@bors
Auto merge of rust-lang#2272 - RalfJung:progress, r=RalfJung
5ac4746 
add -Zmiri-report-progress to regularly print a stacktrace of what we are executing

Fixes rust-lang/miri#910

The stacktrace is printed every N basic blocks. I picked the default (1 million) to take a few seconds on my machine, but it can be adjusted by the user.
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
@adpaco-aws
RFC: The kani::should_panic attribute (rust-lang#2272)
38d1f6f
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
@adpaco-aws
Rethink should_panic and fail_uncoverable options as global condi…
fd12a28 
…tions (rust-lang#2967)

This PR is the next step to rework/introduce the
`should_panic`/`fail_uncoverable` options as global conditions.

Until now, we haven't had a concrete proposal to do so other than the
implementation in rust-lang#2532. This PR presents one for each option in their
respective RFCs. I'd like to agree on this design before starting the
code review for rust-lang#2532.

Related to rust-lang#1905 rust-lang#2272 rust-lang#2299 rust-lang#2516
jieyouxu added a commit to jieyouxu/rust that referenced this issue Mar 11, 2025
@jieyouxu
Merge pull request rust-lang#2272 from rust-lang/tshepang-patch-2
d9c920b 
compiletest directives: ignore-stage0 and only-stage0 do not exist
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@brson brson

Labels
None yet
Projects
None yet
Milestone
0.3
Development

No branches or pull requests
3 participants
@marijnh @brson @catamorphism