[CONJ-901] ArrayIndexOutOfBoundsException on StandardReadableByteBuf.readByte Created: 2021-10-01  Updated: 2021-10-22  Resolved: 2021-10-22

Status: Closed
Project: MariaDB Connector/J
Component/s: Other
Affects Version/s: 3.0.2-rc
Fix Version/s: 3.0.3

Type: Bug Priority: Major
Reporter: Sebastian Stamm Assignee: Diego Dupin
Resolution: Fixed Votes: 0
Labels: None


 Description    

java.lang.ArrayIndexOutOfBoundsException: 46
 
	at org.mariadb.jdbc.client.impl.StandardReadableByteBuf.readByte(StandardReadableByteBuf.java:134)
 
	at org.mariadb.jdbc.message.server.ColumnDefinitionPacket.<init>(ColumnDefinitionPacket.java:59)
 
	at org.mariadb.jdbc.message.server.PrepareResultPacket.<init>(PrepareResultPacket.java:42)
 
	at org.mariadb.jdbc.message.client.PreparePacket.readPacket(PreparePacket.java:89)
 
	at org.mariadb.jdbc.client.impl.StandardClient.readPacket(StandardClient.java:698)
 
	at org.mariadb.jdbc.client.impl.StandardClient.readResults(StandardClient.java:644)
 
	at org.mariadb.jdbc.client.impl.StandardClient.readResponse(StandardClient.java:569)
 
	at org.mariadb.jdbc.client.impl.StandardClient.executePipeline(StandardClient.java:487)
 
	at org.mariadb.jdbc.ClientPreparedStatement.executeBatchBulk(ClientPreparedStatement.java:115)
 
	at org.mariadb.jdbc.ClientPreparedStatement.executeInternalPreparedBatch(ClientPreparedStatement.java:91)
 
	at org.mariadb.jdbc.ClientPreparedStatement.executeBatch(ClientPreparedStatement.java:412)
 
	at org.hibernate.engine.jdbc.batch.internal.BatchingBatch.performExecution(BatchingBatch.java:121)
 
	at org.hibernate.engine.jdbc.batch.internal.BatchingBatch.doExecuteBatch(BatchingBatch.java:106)
 
	at org.hibernate.engine.jdbc.batch.internal.AbstractBatchImpl.execute(AbstractBatchImpl.java:148)
 
	at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.executeBatch(JdbcCoordinatorImpl.java:198)
 
	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:633)
 
	at org.hibernate.engine.spi.ActionQueue.executeInserts(ActionQueue.java:461)
 
	at org.hibernate.engine.spi.ActionQueue.addInsertAction(ActionQueue.java:258)
 
	at org.hibernate.engine.spi.ActionQueue.addAction(ActionQueue.java:317)
 
	at org.hibernate.event.internal.AbstractSaveEventListener.addInsertAction(AbstractSaveEventListener.java:330)
 
	at org.hibernate.event.internal.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:287)
 
	at org.hibernate.event.internal.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:193)
 
	at org.hibernate.event.internal.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:123)
 
	at org.hibernate.event.internal.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:185)
 
	at org.hibernate.event.internal.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:128)
 
	at org.hibernate.event.internal.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:55)
 
	at org.hibernate.event.service.internal.EventListenerGroupImpl.fireEventOnEachListener(EventListenerGroupImpl.java:107)
 
	at org.hibernate.internal.SessionImpl.firePersist(SessionImpl.java:749)
 
	at org.hibernate.internal.SessionImpl.persist(SessionImpl.java:735)
 
	at sun.reflect.GeneratedMethodAccessor92.invoke(Unknown Source)
 
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 
	at java.lang.reflect.Method.invoke(Method.java:498)
 
	at org.hibernate.context.internal.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:351)
 
	at com.sun.proxy.$Proxy55.persist(Unknown Source)



 Comments   
Comment by Diego Dupin [ 2021-10-22 ]

There is some race condition somewhere.
I've reproduced the issue executing prepared statement using binary protocol 1M time when prepare doesn't hit cache, only for 10.6 server.

Comment by Diego Dupin [ 2021-10-22 ]

corrected with this commit

Problem was that even if client explicitly disable skipping metadata when using mariadb server 10.6, client wrongly parse column-count-packet.
Since column count packet is retrieved in a reused buffer, driver uncorrectly read metadata skip flag. That value will then be set to a random byte value from a previous exchanged packet. If by misluck value was 0x00, then driver wrongly skip meta, considering next metadata packet as a row packet, resulting in those parsing error.

Generated at Thu Feb 08 03:19:09 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.