NPE after upgrade from 4.1.6 to 4.1.8

Description

From my post on the mailing list:

Hi,

After upgrading from 4.1.6 to 4.1.8, we have a couple of regressions
in one of our applications.

We tried to obtain self contained test cases and understand what the
problem is but it's quite hard to reproduce and we haven't found a way
to isolate the problem yet.

Anyway, I was wondering if the stacktraces could ring a bell for
someone to help us analyze the problem. It might even be an obvious
bug for you once you have the stracktrace.

Stacktrace 1 (only when we configure the batch loading - might be due
to a race condition because it's not systematic):

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Caused by: java.lang.NullPointerException at org.hibernate.type.descriptor.java.AbstractTypeDescriptor.extractHashCode(AbstractTypeDescriptor.java:88) at org.hibernate.type.AbstractStandardBasicType.getHashCode(AbstractStandardBasicType.java:210) at org.hibernate.type.AbstractStandardBasicType.getHashCode(AbstractStandardBasicType.java:214) at org.hibernate.cache.spi.CacheKey.calculateHashCode(CacheKey.java:71) at org.hibernate.cache.spi.CacheKey.<init>(CacheKey.java:67) at org.hibernate.internal.AbstractSessionImpl.generateCacheKey(AbstractSessionImpl.java:252) at org.hibernate.engine.spi.BatchFetchQueue.isCached(BatchFetchQueue.java:330) at org.hibernate.engine.spi.BatchFetchQueue.getCollectionBatch(BatchFetchQueue.java:312) at org.hibernate.loader.collection.BatchingCollectionInitializer.initialize(BatchingCollectionInitializer.java:72) at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:678) at org.hibernate.event.internal.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:80) at org.hibernate.internal.SessionImpl.initializeCollection(SessionImpl.java:1804) at org.hibernate.collection.internal.AbstractPersistentCollection$4.doWork(AbstractPersistentCollection.java:549) at org.hibernate.collection.internal.AbstractPersistentCollection.withTemporarySessionIfNeeded(AbstractPersistentCollection.java:234) at org.hibernate.collection.internal.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:545) at org.hibernate.collection.internal.PersistentBag.removeAll(PersistentBag.java:345)

Followup of this post:
The errors are quite hard to reproduce and we only have them in a big application with a lot of entities when we are bulk loading a lot of objects. We don't reproduce these problems on the smaller ones. That's why a self contained test case is hard to get.

They are totally reproducable on this application though.

Should we try to reproduce it in a debug environment with a conditional breakpoint to see if we can have more information about the context?

In this commit, I find a little weird that the hashCode is tested before testing the type but I don't think it might be related to the problem at hand.
https://github.com/hibernate/hibernate-orm/commit/fae0d3f49877a5a11a7ac5cef25bb91235906fab

Environment

Hibernate 4.1.8, PostgreSQL 9.1

Status

Assignee

Brett Meyer

Reporter

Guillaume Smet

Fix versions

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

4.1.8

Priority

Major