large dictionary literal overflows swiftc stack

Development Compiler
1

Attached is a file from a project called PerfectLib that contains a dictionary literal with 816 entries in it. On my system with exactly 559 entries (meaning the last entry is "res") the file can be compiled, but with 560 or more it crashes. It looks like the crash is an infinite loop, I see many entries like this in the stack trace.

frame #3351: 0x000000000199e0fe swift`tryTypeVariableBindings(cs=0x00007fffffff82e8, depth=12, typeVar=0x0000000007edba58, bindings=ArrayRef<(anonymous namespace)::PotentialBinding> @ 0x00007ffffffe00f8, solutions=0x00007fffffff7660, allowFreeTypeVariables=Disallow)::PotentialBinding>, llvm::SmallVectorImpl<swift::constraints::Solution>&, swift::FreeTypeVariableBinding) + 1294 at CSSolver.cpp:1078
    frame #3352: 0x000000000199cdef swift`swift::constraints::ConstraintSystem::solveSimplified(this=0x00007fffffff82e8, solutions=0x00007fffffff7660, allowFreeTypeVariables=Disallow) + 879 at CSSolver.cpp:1551
    frame #3353: 0x000000000199b7c0 swift`swift::constraints::ConstraintSystem::solveRec(this=0x00007fffffff82e8, solutions=0x00007fffffff7660, allowFreeTypeVariables=Disallow) + 608 at CSSolver.cpp:1256
    frame #3354: 0x000000000199e0fe swift`tryTypeVariableBindings(cs=0x00007fffffff82e8, depth=11, typeVar=0x0000000007eca470, bindings=ArrayRef<(anonymous namespace)::PotentialBinding> @ 0x00007ffffffe1de8, solutions=0x00007fffffff7660, allowFreeTypeVariables=Disallow)::PotentialBinding>, llvm::SmallVectorImpl<swift::constraints::Solution>&, swift::FreeTypeVariableBinding) + 1294 at CSSolver.cpp:1078
    frame #3355: 0x000000000199cdef swift`swift::constraints::ConstraintSystem::solveSimplified(this=0x00007fffffff82e8, solutions=0x00007fffffff7660, allowFreeTypeVariables=Disallow) + 879 at CSSolver.cpp:1551
    frame #3356: 0x000000000199b7c0 swift`swift::constraints::ConstraintSystem::solveRec(this=0x00007fffffff82e8, solutions=0x00007fffffff7660, allowFreeTypeVariables=Disallow) + 608 at CSSolver.cpp:1256

The bottom of the stack is

frame #3391: 0x00000000017d21d9 swift`swift::TypeChecker::solveForExpression(this=0x00007fffffff97e0, expr=0x00007fffffff8fe0, dc=0x0000000007ead5c0, convertType=Type @ 0x00007fffffff7518, allowFreeTypeVariables=Disallow, listener=0x00007fffffff8f50, cs=0x00007fffffff82e8, viable=0x00007fffffff7660, options=(Storage = 16)) + 665 at TypeCheckConstraints.cpp:1154
    frame #3392: 0x00000000017d4ae7 swift`swift::TypeChecker::typeCheckExpression(this=0x00007fffffff97e0, expr=0x00007fffffff8fe0, dc=0x0000000007ead5c0, convertType=Type @ 0x00007fffffff8e48, convertTypePurpose=CTP_Unused, options=(Storage = 16), listener=0x00007fffffff8f50) + 711 at TypeCheckConstraints.cpp:1304
    frame #3393: 0x00000000017d61f5 swift`swift::TypeChecker::typeCheckBinding(this=0x00007fffffff97e0, pattern=0x00007fffffff8fe8, initializer=0x00007fffffff8fe0, DC=0x0000000007ead5c0) + 261 at TypeCheckConstraints.cpp:1624
    frame #3394: 0x00000000017d64cd swift`swift::TypeChecker::typeCheckPatternBinding(this=0x00007fffffff97e0, PBD=0x0000000007ed3fe8, patternNumber=0) + 237 at TypeCheckConstraints.cpp:1674
    frame #3395: 0x0000000001809eb1 swift`validatePatternBindingDecl(tc=0x00007fffffff97e0, binding=0x0000000007ed3fe8, entryNumber=0) + 1025 at TypeCheckDecl.cpp:1214
    frame #3396: 0x00000000018126b3 swift`(anonymous namespace)::DeclChecker::visitPatternBindingDecl(this=0x00007fffffff93b0, PBD=0x0000000007ed3fe8) + 83 at TypeCheckDecl.cpp:2842
    frame #3397: 0x00000000018117ac swift`swift::ASTVisitor<(anonymous namespace)::DeclChecker, void, void, void, void, void, void>::visit(this=0x00007fffffff93b0, D=0x0000000007ed3fe8) + 140 at DeclNodes.def:91
    frame #3398: 0x00000000018076f7 swift`(anonymous namespace)::DeclChecker::visit(this=0x00007fffffff93b0, decl=0x0000000007ed3fe8) + 39 at TypeCheckDecl.cpp:2672
    frame #3399: 0x0000000001807650 swift`swift::TypeChecker::typeCheckDecl(this=0x00007fffffff97e0, D=0x0000000007ed3fe8, isFirstPass=false) + 160 at TypeCheckDecl.cpp:5561
    frame #3400: 0x00000000018ca5ce swift`(anonymous namespace)::StmtChecker::visitBraceStmt(this=0x00007fffffff9600, BS=0x0000000007ed4038) + 1166 at TypeCheckStmt.cpp:1078
    frame #3401: 0x00000000018c9f0b swift`swift::ASTVisitor<(anonymous namespace)::StmtChecker, void, swift::Stmt*, void, void, void, void>::visit(this=0x00007fffffff9600, S=0x0000000007ed4038) + 91 at StmtNodes.def:43
    frame #3402: 0x00000000018c99fa swift`bool (anonymous namespace)::StmtChecker::typeCheckStmt<swift::BraceStmt>(this=0x00007fffffff9600, S=0x00007fffffff9668) + 42 at TypeCheckStmt.cpp:325
    frame #3403: 0x00000000018c98e4 swift`swift::TypeChecker::typeCheckTopLevelCodeDecl(this=0x00007fffffff97e0, TLCD=0x0000000007ead590) + 132 at TypeCheckStmt.cpp:1405
    frame #3404: 0x00000000017b1524 swift`swift::performTypeChecking(SF=0x0000000007ead380, TLC=0x00007fffffffa068, Options=(Storage = 5), StartElem=0) + 900 at TypeChecker.cpp:585
    frame #3405: 0x0000000001515e08 swift`swift::CompilerInstance::performSema(this=0x00007fffffffb680) + 5048 at Frontend.cpp:464
    frame #3406: 0x0000000000c5e42c swift`performCompile(Instance=0x00007fffffffb680, Invocation=0x00007fffffffb250, Args=ArrayRef<const char *> @ 0x00007fffffffad50, ReturnValue=0x00007fffffffaf34) + 1500 at frontend_main.cpp:666
    frame #3407: 0x0000000000c5da75 swift`frontend_main(Args=ArrayRef<const char *> @ 0x00007fffffffc188, Argv0="/home/jon/tmp/swift/swift/install/bin/swift", MainAddr=0x0000000000c4c010) + 2981 at frontend_main.cpp:1117
    frame #3408: 0x0000000000c4cc3e swift`main(argc_=10, argv_=0x00007fffffffdba8) + 3054 at driver.cpp:156
    frame #3409: 0x00007ffff6375ec5 libc.so.6`__libc_start_main(main=(swift`main at driver.cpp:107), argc=10, argv=0x00007fffffffdba8, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007fffffffdb98) + 245 at libc-start.c:287
    frame #3410: 0x0000000000c4bf44 swift`_start + 41

This crash is on linux using swift 2.2 @ c9e72b3a9290a78d. I haven't tried the swift-2.2-RELEASE tag, but it will probably have the same behavior as my current git checkout is pretty close (in terms of commits) to the release tag. Curiously on osx the native swift binary does not have a problem with this file.

My own code built on top of the swift codebase on osx does crash, however. I am currently investigating what differences there are between how I invoke the swift type checker and how the native swiftc does it.

···

--

2

I'd recommend testing to see if this is improved in Swift 3, if it's practical to switch your codebase over. There are some type checker improvements there that didn't make it into Swift 2.

-Joe

···

On Mar 22, 2016, at 12:13 PM, Rafkind, Jon via swift-dev <swift-dev@swift.org> wrote:

Attached is a file from a project called PerfectLib that contains a dictionary literal with 816 entries in it. On my system with exactly 559 entries (meaning the last entry is "res") the file can be compiled, but with 560 or more it crashes. It looks like the crash is an infinite loop, I see many entries like this in the stack trace.

frame #3351: 0x000000000199e0fe swift`tryTypeVariableBindings(cs=0x00007fffffff82e8, depth=12, typeVar=0x0000000007edba58, bindings=ArrayRef<(anonymous namespace)::PotentialBinding> @ 0x00007ffffffe00f8, solutions=0x00007fffffff7660, allowFreeTypeVariables=Disallow)::PotentialBinding>, llvm::SmallVectorImpl<swift::constraints::Solution>&, swift::FreeTypeVariableBinding) + 1294 at CSSolver.cpp:1078
   frame #3352: 0x000000000199cdef swift`swift::constraints::ConstraintSystem::solveSimplified(this=0x00007fffffff82e8, solutions=0x00007fffffff7660, allowFreeTypeVariables=Disallow) + 879 at CSSolver.cpp:1551
   frame #3353: 0x000000000199b7c0 swift`swift::constraints::ConstraintSystem::solveRec(this=0x00007fffffff82e8, solutions=0x00007fffffff7660, allowFreeTypeVariables=Disallow) + 608 at CSSolver.cpp:1256
   frame #3354: 0x000000000199e0fe swift`tryTypeVariableBindings(cs=0x00007fffffff82e8, depth=11, typeVar=0x0000000007eca470, bindings=ArrayRef<(anonymous namespace)::PotentialBinding> @ 0x00007ffffffe1de8, solutions=0x00007fffffff7660, allowFreeTypeVariables=Disallow)::PotentialBinding>, llvm::SmallVectorImpl<swift::constraints::Solution>&, swift::FreeTypeVariableBinding) + 1294 at CSSolver.cpp:1078
   frame #3355: 0x000000000199cdef swift`swift::constraints::ConstraintSystem::solveSimplified(this=0x00007fffffff82e8, solutions=0x00007fffffff7660, allowFreeTypeVariables=Disallow) + 879 at CSSolver.cpp:1551
   frame #3356: 0x000000000199b7c0 swift`swift::constraints::ConstraintSystem::solveRec(this=0x00007fffffff82e8, solutions=0x00007fffffff7660, allowFreeTypeVariables=Disallow) + 608 at CSSolver.cpp:1256

The bottom of the stack is

frame #3391: 0x00000000017d21d9 swift`swift::TypeChecker::solveForExpression(this=0x00007fffffff97e0, expr=0x00007fffffff8fe0, dc=0x0000000007ead5c0, convertType=Type @ 0x00007fffffff7518, allowFreeTypeVariables=Disallow, listener=0x00007fffffff8f50, cs=0x00007fffffff82e8, viable=0x00007fffffff7660, options=(Storage = 16)) + 665 at TypeCheckConstraints.cpp:1154
   frame #3392: 0x00000000017d4ae7 swift`swift::TypeChecker::typeCheckExpression(this=0x00007fffffff97e0, expr=0x00007fffffff8fe0, dc=0x0000000007ead5c0, convertType=Type @ 0x00007fffffff8e48, convertTypePurpose=CTP_Unused, options=(Storage = 16), listener=0x00007fffffff8f50) + 711 at TypeCheckConstraints.cpp:1304
   frame #3393: 0x00000000017d61f5 swift`swift::TypeChecker::typeCheckBinding(this=0x00007fffffff97e0, pattern=0x00007fffffff8fe8, initializer=0x00007fffffff8fe0, DC=0x0000000007ead5c0) + 261 at TypeCheckConstraints.cpp:1624
   frame #3394: 0x00000000017d64cd swift`swift::TypeChecker::typeCheckPatternBinding(this=0x00007fffffff97e0, PBD=0x0000000007ed3fe8, patternNumber=0) + 237 at TypeCheckConstraints.cpp:1674
   frame #3395: 0x0000000001809eb1 swift`validatePatternBindingDecl(tc=0x00007fffffff97e0, binding=0x0000000007ed3fe8, entryNumber=0) + 1025 at TypeCheckDecl.cpp:1214
   frame #3396: 0x00000000018126b3 swift`(anonymous namespace)::DeclChecker::visitPatternBindingDecl(this=0x00007fffffff93b0, PBD=0x0000000007ed3fe8) + 83 at TypeCheckDecl.cpp:2842
   frame #3397: 0x00000000018117ac swift`swift::ASTVisitor<(anonymous namespace)::DeclChecker, void, void, void, void, void, void>::visit(this=0x00007fffffff93b0, D=0x0000000007ed3fe8) + 140 at DeclNodes.def:91
   frame #3398: 0x00000000018076f7 swift`(anonymous namespace)::DeclChecker::visit(this=0x00007fffffff93b0, decl=0x0000000007ed3fe8) + 39 at TypeCheckDecl.cpp:2672
   frame #3399: 0x0000000001807650 swift`swift::TypeChecker::typeCheckDecl(this=0x00007fffffff97e0, D=0x0000000007ed3fe8, isFirstPass=false) + 160 at TypeCheckDecl.cpp:5561
   frame #3400: 0x00000000018ca5ce swift`(anonymous namespace)::StmtChecker::visitBraceStmt(this=0x00007fffffff9600, BS=0x0000000007ed4038) + 1166 at TypeCheckStmt.cpp:1078
   frame #3401: 0x00000000018c9f0b swift`swift::ASTVisitor<(anonymous namespace)::StmtChecker, void, swift::Stmt*, void, void, void, void>::visit(this=0x00007fffffff9600, S=0x0000000007ed4038) + 91 at StmtNodes.def:43
   frame #3402: 0x00000000018c99fa swift`bool (anonymous namespace)::StmtChecker::typeCheckStmt<swift::BraceStmt>(this=0x00007fffffff9600, S=0x00007fffffff9668) + 42 at TypeCheckStmt.cpp:325
   frame #3403: 0x00000000018c98e4 swift`swift::TypeChecker::typeCheckTopLevelCodeDecl(this=0x00007fffffff97e0, TLCD=0x0000000007ead590) + 132 at TypeCheckStmt.cpp:1405
   frame #3404: 0x00000000017b1524 swift`swift::performTypeChecking(SF=0x0000000007ead380, TLC=0x00007fffffffa068, Options=(Storage = 5), StartElem=0) + 900 at TypeChecker.cpp:585
   frame #3405: 0x0000000001515e08 swift`swift::CompilerInstance::performSema(this=0x00007fffffffb680) + 5048 at Frontend.cpp:464
   frame #3406: 0x0000000000c5e42c swift`performCompile(Instance=0x00007fffffffb680, Invocation=0x00007fffffffb250, Args=ArrayRef<const char *> @ 0x00007fffffffad50, ReturnValue=0x00007fffffffaf34) + 1500 at frontend_main.cpp:666
   frame #3407: 0x0000000000c5da75 swift`frontend_main(Args=ArrayRef<const char *> @ 0x00007fffffffc188, Argv0="/home/jon/tmp/swift/swift/install/bin/swift", MainAddr=0x0000000000c4c010) + 2981 at frontend_main.cpp:1117
   frame #3408: 0x0000000000c4cc3e swift`main(argc_=10, argv_=0x00007fffffffdba8) + 3054 at driver.cpp:156
   frame #3409: 0x00007ffff6375ec5 libc.so.6`__libc_start_main(main=(swift`main at driver.cpp:107), argc=10, argv=0x00007fffffffdba8, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007fffffffdb98) + 245 at libc-start.c:287
   frame #3410: 0x0000000000c4bf44 swift`_start + 41

This crash is on linux using swift 2.2 @ c9e72b3a9290a78d. I haven't tried the swift-2.2-RELEASE tag, but it will probably have the same behavior as my current git checkout is pretty close (in terms of commits) to the release tag. Curiously on osx the native swift binary does not have a problem with this file.

My own code built on top of the swift codebase on osx does crash, however. I am currently investigating what differences there are between how I invoke the swift type checker and how the native swiftc does it.

--
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

3

I have to support swift 2.2 for the time being because I have to support the current release of xcode. I will upgrade to swift 3 when it is released.

BTW it doesnt look like my attachment made it, so here is a link to the file:

https://github.com/PerfectlySoft/Perfect/blob/master/PerfectLib/MimeType.swift

···

On 03/22/2016 12:15 PM, Joe Groff wrote:

I'd recommend testing to see if this is improved in Swift 3, if it's practical to switch your codebase over. There are some type checker improvements there that didn't make it into Swift 2.

-Joe

On Mar 22, 2016, at 12:13 PM, Rafkind, Jon via swift-dev <swift-dev@swift.org><mailto:swift-dev@swift.org> wrote:

Attached is a file from a project called PerfectLib that contains a dictionary literal with 816 entries in it. On my system with exactly 559 entries (meaning the last entry is "res") the file can be compiled, but with 560 or more it crashes. It looks like the crash is an infinite loop, I see many entries like this in the stack trace.

frame #3351: 0x000000000199e0fe swift`tryTypeVariableBindings(cs=0x00007fffffff82e8, depth=12, typeVar=0x0000000007edba58, bindings=ArrayRef<(anonymous namespace)::PotentialBinding> @ 0x00007ffffffe00f8, solutions=0x00007fffffff7660, allowFreeTypeVariables=Disallow)::PotentialBinding>, llvm::SmallVectorImpl<swift::constraints::Solution>&, swift::FreeTypeVariableBinding) + 1294 at CSSolver.cpp:1078
   frame #3352: 0x000000000199cdef swift`swift::constraints::ConstraintSystem::solveSimplified(this=0x00007fffffff82e8, solutions=0x00007fffffff7660, allowFreeTypeVariables=Disallow) + 879 at CSSolver.cpp:1551
   frame #3353: 0x000000000199b7c0 swift`swift::constraints::ConstraintSystem::solveRec(this=0x00007fffffff82e8, solutions=0x00007fffffff7660, allowFreeTypeVariables=Disallow) + 608 at CSSolver.cpp:1256
   frame #3354: 0x000000000199e0fe swift`tryTypeVariableBindings(cs=0x00007fffffff82e8, depth=11, typeVar=0x0000000007eca470, bindings=ArrayRef<(anonymous namespace)::PotentialBinding> @ 0x00007ffffffe1de8, solutions=0x00007fffffff7660, allowFreeTypeVariables=Disallow)::PotentialBinding>, llvm::SmallVectorImpl<swift::constraints::Solution>&, swift::FreeTypeVariableBinding) + 1294 at CSSolver.cpp:1078
   frame #3355: 0x000000000199cdef swift`swift::constraints::ConstraintSystem::solveSimplified(this=0x00007fffffff82e8, solutions=0x00007fffffff7660, allowFreeTypeVariables=Disallow) + 879 at CSSolver.cpp:1551
   frame #3356: 0x000000000199b7c0 swift`swift::constraints::ConstraintSystem::solveRec(this=0x00007fffffff82e8, solutions=0x00007fffffff7660, allowFreeTypeVariables=Disallow) + 608 at CSSolver.cpp:1256

The bottom of the stack is

frame #3391: 0x00000000017d21d9 swift`swift::TypeChecker::solveForExpression(this=0x00007fffffff97e0, expr=0x00007fffffff8fe0, dc=0x0000000007ead5c0, convertType=Type @ 0x00007fffffff7518, allowFreeTypeVariables=Disallow, listener=0x00007fffffff8f50, cs=0x00007fffffff82e8, viable=0x00007fffffff7660, options=(Storage = 16)) + 665 at TypeCheckConstraints.cpp:1154
   frame #3392: 0x00000000017d4ae7 swift`swift::TypeChecker::typeCheckExpression(this=0x00007fffffff97e0, expr=0x00007fffffff8fe0, dc=0x0000000007ead5c0, convertType=Type @ 0x00007fffffff8e48, convertTypePurpose=CTP_Unused, options=(Storage = 16), listener=0x00007fffffff8f50) + 711 at TypeCheckConstraints.cpp:1304
   frame #3393: 0x00000000017d61f5 swift`swift::TypeChecker::typeCheckBinding(this=0x00007fffffff97e0, pattern=0x00007fffffff8fe8, initializer=0x00007fffffff8fe0, DC=0x0000000007ead5c0) + 261 at TypeCheckConstraints.cpp:1624
   frame #3394: 0x00000000017d64cd swift`swift::TypeChecker::typeCheckPatternBinding(this=0x00007fffffff97e0, PBD=0x0000000007ed3fe8, patternNumber=0) + 237 at TypeCheckConstraints.cpp:1674
   frame #3395: 0x0000000001809eb1 swift`validatePatternBindingDecl(tc=0x00007fffffff97e0, binding=0x0000000007ed3fe8, entryNumber=0) + 1025 at TypeCheckDecl.cpp:1214
   frame #3396: 0x00000000018126b3 swift`(anonymous namespace)::DeclChecker::visitPatternBindingDecl(this=0x00007fffffff93b0, PBD=0x0000000007ed3fe8) + 83 at TypeCheckDecl.cpp:2842
   frame #3397: 0x00000000018117ac swift`swift::ASTVisitor<(anonymous namespace)::DeclChecker, void, void, void, void, void, void>::visit(this=0x00007fffffff93b0, D=0x0000000007ed3fe8) + 140 at DeclNodes.def:91
   frame #3398: 0x00000000018076f7 swift`(anonymous namespace)::DeclChecker::visit(this=0x00007fffffff93b0, decl=0x0000000007ed3fe8) + 39 at TypeCheckDecl.cpp:2672
   frame #3399: 0x0000000001807650 swift`swift::TypeChecker::typeCheckDecl(this=0x00007fffffff97e0, D=0x0000000007ed3fe8, isFirstPass=false) + 160 at TypeCheckDecl.cpp:5561
   frame #3400: 0x00000000018ca5ce swift`(anonymous namespace)::StmtChecker::visitBraceStmt(this=0x00007fffffff9600, BS=0x0000000007ed4038) + 1166 at TypeCheckStmt.cpp:1078
   frame #3401: 0x00000000018c9f0b swift`swift::ASTVisitor<(anonymous namespace)::StmtChecker, void, swift::Stmt*, void, void, void, void>::visit(this=0x00007fffffff9600, S=0x0000000007ed4038) + 91 at StmtNodes.def:43
   frame #3402: 0x00000000018c99fa swift`bool (anonymous namespace)::StmtChecker::typeCheckStmt<swift::BraceStmt>(this=0x00007fffffff9600, S=0x00007fffffff9668) + 42 at TypeCheckStmt.cpp:325
   frame #3403: 0x00000000018c98e4 swift`swift::TypeChecker::typeCheckTopLevelCodeDecl(this=0x00007fffffff97e0, TLCD=0x0000000007ead590) + 132 at TypeCheckStmt.cpp:1405
   frame #3404: 0x00000000017b1524 swift`swift::performTypeChecking(SF=0x0000000007ead380, TLC=0x00007fffffffa068, Options=(Storage = 5), StartElem=0) + 900 at TypeChecker.cpp:585
   frame #3405: 0x0000000001515e08 swift`swift::CompilerInstance::performSema(this=0x00007fffffffb680) + 5048 at Frontend.cpp:464
   frame #3406: 0x0000000000c5e42c swift`performCompile(Instance=0x00007fffffffb680, Invocation=0x00007fffffffb250, Args=ArrayRef<const char *> @ 0x00007fffffffad50, ReturnValue=0x00007fffffffaf34) + 1500 at frontend_main.cpp:666
   frame #3407: 0x0000000000c5da75 swift`frontend_main(Args=ArrayRef<const char *> @ 0x00007fffffffc188, Argv0="/home/jon/tmp/swift/swift/install/bin/swift", MainAddr=0x0000000000c4c010) + 2981 at frontend_main.cpp:1117
   frame #3408: 0x0000000000c4cc3e swift`main(argc_=10, argv_=0x00007fffffffdba8) + 3054 at driver.cpp:156
   frame #3409: 0x00007ffff6375ec5 libc.so.6`__libc_start_main(main=(swift`main at driver.cpp:107), argc=10, argv=0x00007fffffffdba8, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007fffffffdb98) + 245 at libc-start.c:287
   frame #3410: 0x0000000000c4bf44 swift`_start + 41

This crash is on linux using swift 2.2 @ c9e72b3a9290a78d. I haven't tried the swift-2.2-RELEASE tag, but it will probably have the same behavior as my current git checkout is pretty close (in terms of commits) to the release tag. Curiously on osx the native swift binary does not have a problem with this file.

My own code built on top of the swift codebase on osx does crash, however. I am currently investigating what differences there are between how I invoke the swift type checker and how the native swiftc does it.

--
_______________________________________________
swift-dev mailing list
swift-dev@swift.org<mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

--

4

I understand your motivation, but I would still recommend trying to
update your code (on a branch) to Swift 3. This way you will get a
preview of the changes, would be able to provide feedback, and maybe
even find issues with the changes that we are making before Swift 3 is
finalized in a release. There is benefit for both your library and
the Swift community.

Dmitri

···

On Tue, Mar 22, 2016 at 12:17 PM, Rafkind, Jon via swift-dev <swift-dev@swift.org> wrote:

I have to support swift 2.2 for the time being because I have to support the current release of xcode. I will upgrade to swift 3 when it is released.

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

5

Ok I will test with swift 3, but just to avoid any confusion I am not a developer on PerfectLib. I was just using that file as a test case for my application that is based on the swiftc code base. My application is designed to consume arbitrary swift 2.2 code. If there is a problem with swift 3 then I suppose it can be fixed, but if swift 3 has no issues then it looks like I have few options for remediation.

···

On 03/22/2016 12:56 PM, Dmitri Gribenko wrote:

On Tue, Mar 22, 2016 at 12:17 PM, Rafkind, Jon via swift-dev <swift-dev@swift.org><mailto:swift-dev@swift.org> wrote:

I have to support swift 2.2 for the time being because I have to support the current release of xcode. I will upgrade to swift 3 when it is released.

I understand your motivation, but I would still recommend trying to
update your code (on a branch) to Swift 3. This way you will get a
preview of the changes, would be able to provide feedback, and maybe
even find issues with the changes that we are making before Swift 3 is
finalized in a release. There is benefit for both your library and
the Swift community.

Dmitri

--

6

FWIW when I compile the swift/llvm 2.2 codebase with RelWithDebInfo there is no crash, but in Debug mode there is a crash. I can live with this for now since I will release my tool in RelWithDebInfo anyway. If I have time I will try to find the root cause behind the crash with Debug.

···

On 03/22/2016 12:56 PM, Dmitri Gribenko wrote:

On Tue, Mar 22, 2016 at 12:17 PM, Rafkind, Jon via swift-dev <swift-dev@swift.org><mailto:swift-dev@swift.org> wrote:

I have to support swift 2.2 for the time being because I have to support the current release of xcode. I will upgrade to swift 3 when it is released.

I understand your motivation, but I would still recommend trying to
update your code (on a branch) to Swift 3. This way you will get a
preview of the changes, would be able to provide feedback, and maybe
even find issues with the changes that we are making before Swift 3 is
finalized in a release. There is benefit for both your library and
the Swift community.

Dmitri

--

7

Did your code compile previously as is with Swift 2.1? We'd like to at least fix any regressions we introduced in 2.2.

-Joe

···

On Mar 22, 2016, at 1:41 PM, Rafkind, Jon <jon.rafkind@hpe.com> wrote:

Ok I will test with swift 3, but just to avoid any confusion I am not a developer on PerfectLib. I was just using that file as a test case for my application that is based on the swiftc code base. My application is designed to consume arbitrary swift 2.2 code. If there is a problem with swift 3 then I suppose it can be fixed, but if swift 3 has no issues then it looks like I have few options for remediation.

8

Ok I will test with swift 3, but just to avoid any confusion I am not a developer on PerfectLib.

I am! Admittedly, that dictionary contains many obsolete mime type mappings which could be pruned (anyone serving Lotus 1-2-3 files?). However, 816 items is not an absurdly large number so it’s likely someone else would have run into this in the near future.

The code does successfully compile for me using the release 2.2 version on my VMWare based Ubuntu 15 system. It also compiles using 3.0.

-Kyle

···

I was just using that file as a test case for my application that is based on the swiftc code base. My application is designed to consume arbitrary swift 2.2 code. If there is a problem with swift 3 then I suppose it can be fixed, but if swift 3 has no issues then it looks like I have few options for remediation.

On 03/22/2016 12:56 PM, Dmitri Gribenko wrote:

On Tue, Mar 22, 2016 at 12:17 PM, Rafkind, Jon via swift-dev > <swift-dev@swift.org><mailto:swift-dev@swift.org>wrote:

I have to support swift 2.2 for the time being because I have to support the current release of xcode. I will upgrade to swift 3 when it is released.

I understand your motivation, but I would still recommend trying to
update your code (on a branch) to Swift 3. This way you will get a
preview of the changes, would be able to provide feedback, and maybe
even find issues with the changes that we are making before Swift 3 is
finalized in a release. There is benefit for both your library and
the Swift community.

Dmitri

--

9

The root cause seems to be the program's stack was simply too small, and not an infinite loop in the type checker. On Linux the default stack size is 8192kb, but at least on my system, I needed to use a minimum of 11884kb.

···

On 03/22/2016 03:35 PM, Rafkind, Jon wrote:
FWIW when I compile the swift/llvm 2.2 codebase with RelWithDebInfo there is no crash, but in Debug mode there is a crash. I can live with this for now since I will release my tool in RelWithDebInfo anyway. If I have time I will try to find the root cause behind the crash with Debug.

On 03/22/2016 12:56 PM, Dmitri Gribenko wrote:

On Tue, Mar 22, 2016 at 12:17 PM, Rafkind, Jon via swift-dev <swift-dev@swift.org><mailto:swift-dev@swift.org> wrote:

I have to support swift 2.2 for the time being because I have to support the current release of xcode. I will upgrade to swift 3 when it is released.

I understand your motivation, but I would still recommend trying to
update your code (on a branch) to Swift 3. This way you will get a
preview of the changes, would be able to provide feedback, and maybe
even find issues with the changes that we are making before Swift 3 is
finalized in a release. There is benefit for both your library and
the Swift community.

Dmitri

--

--

10

I ran a test to see the maximum number of elements swift could handle before crashing and the numbers are

swift 2.2: 1213
swift 3-dev (mar 16 snapshot): 976

I don't know why swift 3 is lower than swift 2.2, but I'm guessing its due to the same underlying cause, which is running out of stack space. If the swift 3 snapshot was compiled with different flags than 2.2 then swift 3 could have different stack usage properties, and thus run out of stack space quicker.

Here is a python script that generates a dictionary literal with some number of elements and runs swift on it, then does binary search to find the maximum number of elements before swift crashes.

#!/usr/bin/env python

def make_swift(n):
    def element(x):
        return '"x%d": "0"' % x

    data = "let n = [";
    data += ',\n'.join([element(x) for x in xrange(0, n)])
    data += "]"

    path = 'test-%d.swift' % n
    file = open(path, 'w')
    file.write(data)
    file.write('\n')
    file.close()
    return path

def translate(path):
    print "Testing %s" % path
    import subprocess
    out = subprocess.call(['swift', path])
    if out == 0:
        print " ok"
    else:
        print " failed"
    return out == 0

def test(n):
    path = make_swift(n)
    return translate(path)

def binary_search(low, high):
    while low < high:
        middle = (low + high) / 2
        if middle == low:
            low = high
            middle = high
        if test(middle):
            low = middle
        else:
            high = middle
    return middle

#test(5000)

low = 1
high = 10
while test(high):
    low = high
    high *= 2

last_failed = binary_search(low, high)
print "Failed at %d" % last_failed

···

On 03/22/2016 09:03 PM, Kyle Jessup via swift-dev wrote:

Ok I will test with swift 3, but just to avoid any confusion I am not a developer on PerfectLib.

I am! Admittedly, that dictionary contains many obsolete mime type mappings which could be pruned (anyone serving Lotus 1-2-3 files?). However, 816 items is not an absurdly large number so it’s likely someone else would have run into this in the near future.

The code does successfully compile for me using the release 2.2 version on my VMWare based Ubuntu 15 system. It also compiles using 3.0.

-Kyle

I was just using that file as a test case for my application that is based on the swiftc code base. My application is designed to consume arbitrary swift 2.2 code. If there is a problem with swift 3 then I suppose it can be fixed, but if swift 3 has no issues then it looks like I have few options for remediation.

On 03/22/2016 12:56 PM, Dmitri Gribenko wrote:

On Tue, Mar 22, 2016 at 12:17 PM, Rafkind, Jon via swift-dev <swift-dev@swift.org><mailto:swift-dev@swift.org><mailto:swift-dev@swift.org><mailto:swift-dev@swift.org>wrote:

I have to support swift 2.2 for the time being because I have to support the current release of xcode. I will upgrade to swift 3 when it is released.

I understand your motivation, but I would still recommend trying to
update your code (on a branch) to Swift 3. This way you will get a
preview of the changes, would be able to provide feedback, and maybe
even find issues with the changes that we are making before Swift 3 is
finalized in a release. There is benefit for both your library and
the Swift community.

Dmitri

--

_______________________________________________
swift-dev mailing list
swift-dev@swift.org<mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

--

11

Thanks for digging into this!

I’m seeing the same thing you are - in Swift 3, we’ve solved the problem for array literals, but dictionary literals are still susceptible. I’ll take a look to see why the current round of optimizations aren’t being applied to them.

- Joe

···

On Mar 23, 2016, at 11:56 AM, Rafkind, Jon via swift-dev <swift-dev@swift.org> wrote:

I ran a test to see the maximum number of elements swift could handle before crashing and the numbers are

swift 2.2: 1213
swift 3-dev (mar 16 snapshot): 976

I don't know why swift 3 is lower than swift 2.2, but I'm guessing its due to the same underlying cause, which is running out of stack space. If the swift 3 snapshot was compiled with different flags than 2.2 then swift 3 could have different stack usage properties, and thus run out of stack space quicker.

Here is a python script that generates a dictionary literal with some number of elements and runs swift on it, then does binary search to find the maximum number of elements before swift crashes.

#!/usr/bin/env python

def make_swift(n):
   def element(x):
       return '"x%d": "0"' % x

   data = "let n = [";
   data += ',\n'.join([element(x) for x in xrange(0, n)])
   data += "]"

   path = 'test-%d.swift' % n
   file = open(path, 'w')
   file.write(data)
   file.write('\n')
   file.close()
   return path

def translate(path):
   print "Testing %s" % path
   import subprocess
   out = subprocess.call(['swift', path])
   if out == 0:
       print " ok"
   else:
       print " failed"
   return out == 0

def test(n):
   path = make_swift(n)
   return translate(path)

def binary_search(low, high):
   while low < high:
       middle = (low + high) / 2
       if middle == low:
           low = high
           middle = high
       if test(middle):
           low = middle
       else:
           high = middle
   return middle

#test(5000)

low = 1
high = 10
while test(high):
   low = high
   high *= 2

last_failed = binary_search(low, high)
print "Failed at %d" % last_failed

On 03/22/2016 09:03 PM, Kyle Jessup via swift-dev wrote:

Ok I will test with swift 3, but just to avoid any confusion I am not a developer on PerfectLib.

I am! Admittedly, that dictionary contains many obsolete mime type mappings which could be pruned (anyone serving Lotus 1-2-3 files?). However, 816 items is not an absurdly large number so it’s likely someone else would have run into this in the near future.

The code does successfully compile for me using the release 2.2 version on my VMWare based Ubuntu 15 system. It also compiles using 3.0.

-Kyle

I was just using that file as a test case for my application that is based on the swiftc code base. My application is designed to consume arbitrary swift 2.2 code. If there is a problem with swift 3 then I suppose it can be fixed, but if swift 3 has no issues then it looks like I have few options for remediation.

On 03/22/2016 12:56 PM, Dmitri Gribenko wrote:

On Tue, Mar 22, 2016 at 12:17 PM, Rafkind, Jon via swift-dev > <swift-dev@swift.org <mailto:swift-dev@swift.org>><mailto:swift-dev@swift.org <mailto:swift-dev@swift.org>><mailto:swift-dev@swift.org <mailto:swift-dev@swift.org>><mailto:swift-dev@swift.org <mailto:swift-dev@swift.org>>wrote:

I have to support swift 2.2 for the time being because I have to support the current release of xcode. I will upgrade to swift 3 when it is released.

I understand your motivation, but I would still recommend trying to
update your code (on a branch) to Swift 3. This way you will get a
preview of the changes, would be able to provide feedback, and maybe
even find issues with the changes that we are making before Swift 3 is
finalized in a release. There is benefit for both your library and
the Swift community.

Dmitri

--

_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org><mailto:swift-dev@swift.org <mailto:swift-dev@swift.org>>
https://lists.swift.org/mailman/listinfo/swift-dev

--
_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev