SQL 2012 SP1: Severe error/EXCEPTION_ACCESS_VIOLATION when SELECTing TOP 1 BIGINT - by Thomas Briggs

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


7
0
Sign in
to vote
ID 779075 Comments
Status Closed Workarounds
Type Bug Repros 5
Opened 2/12/2013 1:19:00 PM
Access Restriction Public

Description

The set of queries below generates a stack dump when run on SQL 2012 SP1.  It runs successfully on SQL 2008 R2.  I believe the problem has something to do with BIGINTs and duplicate possible return values.  Removing any one of the rows, or "shortening" any of the AccountId values (e.g. remove the leading 830362286364 from each value) eliminates the problem.  Removing the "TOP 1" or the ORDER BY from the query also eliminates the problem, as does changing the "TOP 1" to "TOP 2" or "TOP 3".

The problem isn't in the query execution either... simply attempting to generate the execution plan is enough to cause the error.

I can provide a crash dump if it helps, but I've been able to reproduce this on every SQL 2012 instance I have access to, so I'm guessing you won't need it. :)
Sign in to post a comment.
Posted by Microsoft on 10/23/2013 at 1:26 PM
Hi Thomas,

Just wanted to let you know that we're planning to have this issue fixed in the next service pack.

Thanks,
Alexey, SQL Development
Posted by Microsoft on 10/23/2013 at 1:25 PM
Hi Thomas,

Just wanted to let you know that we're planning to have this issue fixed in the next service pack.

Thanks,
Alexey, SQL Development
Posted by Thomas Briggs on 3/8/2013 at 4:07 PM
Other forms of the query that also crash:

SELECT MIN(AccountId) ... ORDER BY AccountId
SELECT AccountId ... ORDER BY AccountId OFFSET 0 FETCH NEXT 1

Interestingly, there is one form of the query that doesn't crash:

SELECT TOP 1 FIRST_VALUE(AccountID) OVER(ORDER BY AccountID) ...
Posted by Thomas Briggs on 3/8/2013 at 12:00 PM
This happened to us again on a different server (same query, similar data, different server) but the plan guide doesn't solve the problem. No longer sure that's a valid workaround, but apparently you can't delete workarounds, so...
Posted by Vishal [MSFT] on 2/13/2013 at 12:14 PM
Thanks for reporting this issue we are looking into this - Vishal
Posted by Glenn A. Berry on 2/13/2013 at 9:00 AM
I can also reproduce this issue on RTM CU5 (build 11.0.2395)
Posted by SQLServerMonkey on 2/13/2013 at 8:16 AM
I can repeat this in SQL Server 2012 SP1 Build number 11.0.3000.0

Have tested the code listed in the details section on SQL Server 2008R2 SP2 Build number 10.50.4270.0 and it returns the expected result.
Posted by Nicholas Cain on 2/13/2013 at 8:06 AM
I can reproduce this in SP1/CU1 (build 11.0.3321)