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-4497] Memory issue causes crash when application built with optimization turned on. #47074

Closed
swift-ci opened this issue Apr 4, 2017 · 5 comments

Comments

@swift-ci
Copy link
Collaborator

@swift-ci swift-ci commented Apr 4, 2017

Previous ID SR-4497
Radar rdar://problem/31459425
Original Reporter anaglik (JIRA User)
Type Bug
Status Resolved
Resolution Duplicate

Attachment: Download

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, 3.1Regression, OptimizedOnly, RunTimeCrash
Assignee @eeckstein
Priority Medium

md5: baaae3d56f01cbf35295f4840f3516f5

duplicates:

  • SR-4393 Miscompilation: object modified after being freed (Swift 3.1 regression)

Issue Description:

I've noticed crashes after I upgraded Swift to version 3.1. It happens only when optimization is set to "-O" or "-O whole-module-optimization"
Here is an example code (Example app crashes when following method is called a few times (usually two is enough).

fileprivate func funWithWords(_ words: [String]) -> [String] {        
        var resultArray = [String]()
        
        for index in 0..<words.count {
            // This will crash
            let pre = words[0...index].reduce("", +)
            resultArray.append(pre)
            
            // This version is ok
//            let pre = words[0...index].reduce("", +)
//            resultArray = resultArray + [pre]
            
            // This version is ok too
//            let pre = words[0...index].joined()
//            resultArray.append(pre)
            
            // This version is ok too
//            let pre = words[0...index]
//            let reduced = pre.reduce("", +)
//            resultArray.append(reduced)
        }
        return resultArray
}

Instruments also detects leak in that code. I am attaching screenshot of stack trace from Instruments and Xcode.
I will verify if issue exists on swift-master as well.

@belkadan
Copy link
Contributor

@belkadan belkadan commented Apr 5, 2017

I tried it and got a miscompile—for a particular call it returned the wrong results. It seems to be working in master, though.

@eeckstein, does this sound familiar? Was there a 'semantics' attribute in the wrong place in 3.1?

@belkadan
Copy link
Contributor

@belkadan belkadan commented Apr 5, 2017

@swift-ci create

@eeckstein
Copy link
Member

@eeckstein eeckstein commented Apr 5, 2017

It's not working on master either. Although the behavior is different.
I'll look at it.

@bob-wilson
Copy link

@bob-wilson bob-wilson commented Apr 5, 2017

This looks like the same thing as SR-4393.

@atrick
Copy link
Member

@atrick atrick commented Apr 6, 2017

I verified this is fixed by

commit 2fce87c
Author: Erik Eckstein <eeckstein@apple.com>
Date: Wed Apr 5 17:02:29 2017

EscapeAnalysis: fix a wrong use-point detection.

This caused redundant load elimination to remove a load although the value is overwritten in a called function.
Most likely this could only occur if the load address is a block argument.

fixes SR-4393

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants