Skip to content

Memory leak when calling span_fatal from trans #2272

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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
Milestone

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
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
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
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
…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
compiletest directives: ignore-stage0 and only-stage0 do not exist
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants