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

[SR-6268] Possible incorrect memory management for boxed types #48818

Closed
compnerd opened this issue Nov 1, 2017 · 6 comments
Closed

[SR-6268] Possible incorrect memory management for boxed types #48818

compnerd opened this issue Nov 1, 2017 · 6 comments
Assignees
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself crash Bug: A crash, i.e., an abnormal termination of software run-time crash Bug → crash: Swift code crashed during execution SILGen Area → compiler: The SIL generation stage

Comments

@compnerd
Copy link
Collaborator

compnerd commented Nov 1, 2017

Previous ID SR-6268
Radar rdar://problem/35296541
Original Reporter @compnerd
Type Bug
Status Resolved
Resolution Done
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, RunTimeCrash, SILGen
Assignee @compnerd
Priority Medium

md5: 57df5705c5cdb0437c9c17d5fbec3537

is duplicated by:

  • SR-4775 SwiftPM is hitting Assertion `object->refCounts.isDeiniting()

Issue Description:

The following test case seems to cause the runtime to abort due to the boxed type being discarded is not marked as Deiniting.

func f() -> Bool? { return nil }
({
   guard var b = f() else { return }
   let c = { b = true }
   _ = (b, c)
})()

/Users/compnerd/Source/apple-swift/swift/stdlib/public/runtime/HeapObject.cpp:781: void swift::swift_deallocObject(swift::HeapObject *, size_t, size_t): Assertion `object->refCounts.isDeiniting()' failed.

@compnerd
Copy link
Collaborator Author

compnerd commented Nov 1, 2017

Verified that this occurs on Linux and Darwin.

@belkadan
Copy link
Contributor

belkadan commented Nov 1, 2017

@swift-ci create

@compnerd
Copy link
Collaborator Author

compnerd commented Nov 2, 2017

Hmm, I suspect that this is a SILGen issue. The following SIL is generated:

sil private @_T04nullyycfU_ : $@convention(thin) () -> () {
bb0:
  %0 = alloc_box ${ var Bool }, var, name "b"
  %1 = project_box %0 : ${ var Bool }, 0
  %2 = function_ref @_T04null1fSbSgyF : $@convention(thin) () -> Optional<Bool>
  %3 = apply %2() : $@convention(thin) () -> Optional<Bool>
  switch_enum %3 : $Optional<Bool>, case #Optional.some!enumelt.1: bb2, case #Optional.none!enumelt: bb1

bb1:
  dealloc_box %0 : ${ var Bool }
  br bb4

bb2(%7 : $Bool):
  store %7 to %1 : $*Bool
  br bb3

bb3:
  %10 = function_ref @_T04nullyycfU_yycfU_ : $@convention(thin) (@owned { var Bool }) -> ()
  strong_retain %0 : ${ var Bool }
  %12 = partial_apply %10(%0) : $@convention(thin) (@owned { var Bool }) -> ()
  debug_value %12 : $@callee_owned () -> (), let, name "c"
  strong_release %12 : $@callee_owned () -> ()
  strong_release %0 : ${ var Bool }
  br bb5

bb4:
  br bb5

bb5:
  %18 = tuple ()
  return %18 : $()
}

In particular, the interesting bit is BB1. The dealloc_box isn't preceded by a set_deallocating instruction for the box.

@gparker42
Copy link
Mannequin

gparker42 mannequin commented Nov 2, 2017

There is also IRGenSILFunction::visitSetDeallocatingInst which omits "unnecessary" set_deallocating instructions. It's possible that this runtime assertion is too strong for our current stack allocation scheme.

@compnerd
Copy link
Collaborator Author

compnerd commented Nov 2, 2017

IRGenSILFunction::visitSetDeallocatingInst is never going to be hit since the SIL itself doesn't have the set_deallocating instruction. AFAICT, we still do a heap allocation via swift_allocObject for the boxed type.

@compnerd
Copy link
Collaborator Author

compnerd commented Nov 2, 2017

Resolved with #12717

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@AnthonyLatsis AnthonyLatsis added the crash Bug: A crash, i.e., an abnormal termination of software label Dec 12, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself crash Bug: A crash, i.e., an abnormal termination of software run-time crash Bug → crash: Swift code crashed during execution SILGen Area → compiler: The SIL generation stage
Projects
None yet
Development

No branches or pull requests

3 participants