StackOverflowError during sql query creation within AbstractQueryImpl.expandParameterLists method

Description

Steps to reproduce:

  1. create HQL query with 2 'in' clauses (like 'select from o where o.f in ( aram ) or o.f in ( aram1 )'

  2. set 'param1' value to be large list (around 10k entries)

  3. set 'param' value to be some non empty and non one element list

  4. execute query

  5. observe StackOverflowError

To reproduce the issue it is needed to ensure that values for 'param1' will be expanded first so that stack overflow will happen on next step during 'param' expansion.

Environment

None

Activity

Show:
Steve Ebersole
October 27, 2015, 7:15 PM

This bug report does not indicate that the reported issue affects version 5.x. Versions prior to 5.x are no longer maintained. It would be a great help to the Hibernate team and community for someone to verify that the reported issue still affects version 5.x. If so, please add the 5.x version that you verified with to the list of affected-versions and attach the (preferably SSCCE) test case you used to do the verification to the report; from there the issues will be looked at during our triage meetings.

For details, see http://in.relation.to/2015/10/27/great-jira-cleanup-2015/

Steve Ebersole
October 28, 2015, 3:25 AM

As part of verifying that this issue affects 5.0, please just set the "Affects version". Leave the "verify-affects-5.0" label and leave the issue in "Awaiting Response" status; these are critical for us to be able to track these verifications and triage them. Thanks.

Christian Beikov
October 29, 2015, 8:40 AM

I just tried out the attached example and I can confirm that the stack overflow still occurs in hibernate 5.

Steve Ebersole
October 29, 2015, 11:59 AM

This is not super high priority for me. If someone wants to take a look, that would be great.

Chris Cranford
April 6, 2016, 5:37 AM

I used a test case where the first list had 15,000 values and the second only had 2 values.

This is still a problem in 5.1 and I thought this was simply a case of replacing a recursive algorithm with an iterative one to address StringHelper's internal replace recursion calls. But once I addressed the recursion with an iterative loop, I found out that the test case sparked another downstream StackOverflowError, but this time inside antlr.

Assignee

Unassigned

Reporter

Stanislav Bernatsky

Fix versions

None

Labels

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

Priority

Major
Configure