We have a problem in our test runs that use Sap.Data.SQLAnywhere. The test run never finishes. Each test case finishes, but the vstest.console execution never finishes because it's waiting on an instance of Sap.Data.SQLAnywhere.SAUnmanagedDll's finalizer. Here's a C# repro, as far as I can narrow it down:
If you compile and run this against .NET 3.5, it prints "BEFORE UNLOAD" but then hangs at the call to AppDomain.Unload(). If I pause in the managed debugger, the .NET finalizer thread has made an unmanaged call at Sap.Data.SQLAnywhere.v3.5.dll!Sap.Data.SQLAnywhere.SAUnmanagedDll.Finalize(). For whatever reason, this call hanging is blocking the finalizer thread. In the unmanaged debugger, the call stack is:
(If you uncomment the //TODO to disable connection pooling, then Unload() is instant.) My version of Sap.Data.SQLAnywhere is Sap.Data.SQLAnywhere.v3.5, Version=17.0.0.10623 It also (hangs on both .NET 4.5, which loads Sap.Data.SQLAnywhere.v4.5, Version=17.0.0.10624 ) Is this a bug in Sap.Data.SQLAnywhere? Is there a way to fix the finalizer hang without disabling connection pooling? Is there some other workaround that would prevent the Unload() hang ? |
Update: This issue has been fixed as of 17.0.0.1298 and will be released in upcoming support packages. Thanks for the concise reproducible - I can also reproduce this using a blank database, without Integrated Logins enabled:
I also can confirm that it seems that disabling connection pooling changes the hang behaviour - I would recommend using that workaround until we can better understand the interaction and provide a fix. I have opened CR #791082 to investigate further. |
I don't know what difference pooling=true or pooling=false could make since connection pooling really doesn't pool integrated logins in the current implementation and the pooling implmentation should be independent of the unmanaged code where the hang seems to be occuring. So if disabling connection pooling would be a viable interim solution to this issue until it can be investigated in more detail. {... at which point I would recommend opening up a support incident and provide your example code and database for review...} I did notice you do not have a catch block in the main part of your code, so might this have something to do with an unhandled exception and side-effects from that maybe? Also if there is something special around the way you have your integrated logins set up and mapped, that may be important to know. There have been some recent corrections made to our integrated login support around group membership but I don't recognize this as being a matching symptom of any of that. Either way the fact that pooling is playing any role in any of this seems very odd and unexpected. HTH |
I don't know whether that is a bug or not, but you can check yourself if it is contained in the latest (and first) released v17 EBF 17.0.0.1211 here:
http://sqlasupport.sap.com/readme/index.html