Issue #2515: Unexpected Exception (Error 990) with ArrayIndexOutOfBoundsException

Hey, I get the following exception:

ODB-Line-Checker Exception: [ObjectDB 2.8.1]
Unexpected exception (Error 990) Generated by OpenJDK 64-Bit Server VM 11.0.2 (on Linux 4.14.71).
Please report this error on http://www.objectdb.com/issue/new
com.objectdb.o.InternalException: java.lang.ArrayIndexOutOfBoundsException: Index 5 out of bounds for length 0
java.lang.ArrayIndexOutOfBoundsException: Index 5 out of bounds for length 0 
at com.objectdb.o.UTY.L(UTY.java:1440)
at com.objectdb.o.ENH.d(ENH.java:104)
at com.objectdb.o.LDR.d(LDR.java:836)
at com.objectdb.o.LDR.n(LDR.java:224)
at com.objectdb.o.OBC.ab(OBC.java:1085)
at com.objectdb.o.OBC.ai(OBC.java:990)
at com.objectdb.o.OBC.Zy(OBC.java:800)
at com.objectdb.o.SRB.a(SRB.java:162)
at com.objectdb.o.QRR.h(QRR.java:565)
at com.objectdb.o.QRR.i(QRR.java:225)
at com.objectdb.jpa.JpaQuery.getResultList(JpaQuery.java:721)
at backend.EventLogEntryService.only50000Rows(EventLogEntryService.java:283)
at backend.EventLogEntryService.lambda$startLineChecker$0(EventLogEntryService.java:327)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)

With following code (Exception happens here: final List<EventLogPersistEntry> results = query.getResultList();) :

private void only50000Rows(EntityManager em) {
    synchronized (mutex) {
      final Query count = em.createQuery("SELECT COUNT(p) FROM EventLogPersistEntry p");
      long rows = 0;
      try {
        rows = (long) count.getSingleResult();
      } catch (final PersistenceException e) {
        return;
      }
      
      // remove all over 50000
      if (rows > 55000) {
        final TypedQuery<EventLogPersistEntry> query = em.createQuery(
            "SELECT p FROM EventLogPersistEntry p ORDER BY p.id DESC", EventLogPersistEntry.class);
        query.setFirstResult(50000);
        final List<EventLogPersistEntry> results = query.getResultList();

        final Query queryDelete = em
            .createQuery("DELETE FROM EventLogPersistEntry p WHERE p.id < :id");
        em.getTransaction().begin();
        final int deletedCount = queryDelete.setParameter("id", results.get(0).getId())
            .executeUpdate();
        em.getTransaction().commit();
      }
    }
  }

Some Notes to the Bug:

• I used the 2.7 version previously
• I had about 8000 "ghost" entries in the Database. When I opened the Database it statet to have that amount of entries but when I executed "SELECT p from EventLogPersistEntry" it resulted in 0 entries.
• Unfortunately I am not able to upload this DataBase for you, since I am not allowed to do that.

Thank you for the report.

The stack trace indicates an unexpected exception during schema evolution, possibly on an attempt to read an old EventLogPersistEntry instance that has to be adjusted to the new type.

Could you please provide more information about the class EventLogPersistEntry and its history? Was it always defined as an entity class?

You wrote that you used version 2.7 before but it is unclear if the issue is new to this version. If you use version 2.7, does it work with no exception?

Could you check the database with the Doctor and report the results?

What do you mean by schema evolution?

These are the fields of the EventLogPersistEntry class:

private long id;
Date date = new Date();
EnumEventLogLevel type = EnumEventLogLevel.ALL;
EnumEventLogSystem system = EnumEventLogSystem.ALL;
String message = "";

This class was created end of 2017. The only change in the class was to add a get method for the id field. But I don't think that has any effect in resulting to corrupt entries. That would happen if I would change the fields of the class itself, am I right?

We upgraded from JDK 1.8 to 11 a few months ago and did some upgrades to the ObjectDb. I did not delete the Database file during these changes. The system where that error occured was installed a few months ago. So it was not affected by every change I just mentioned. However 2.7 had the exact same errors on that system.

What do you mean by checking it with the doctor?

Best regards

Adding methods is not considered as a schema change, and anyway schema changes to an en entity class are not expected to corrupt the database. The cause of this issue is unclear. Unfortunately the stack trace is not sufficient in this case to understand what exactly happens.

One possible direction could be that the class lost its schema history (the stack trace indicates an attempt to retrieve an object with schema version 5 out of 0 available) due to a temporary situation in which EventLogPersistEntry was reported to ObjectDB by the application as a non entity class (e.g. if it was changed to enum, or the @Entity annotation was removed, etc.). But this is only a guess.

Any further information I can supply to you in this case?

You may post the output of the ObjectDB Doctor, although it is possible that the Doctor will also throw an exception in this case. It doesn't seem as an issue that the Doctor can fix but you may try fixing the database with the Doctor.

Is it the only class with an issue?

If the data is critical for you and you don't have a backup then we may be able to fix the database manually if you send the database + if possible also an older version of this database without the issue, to extract the missing old schema from.

I have put the output of the Doctor in the attached text file. Hope this helps.

I don't need that Database repaired since it is from our development system. And unfortunately I am not allowed to send you the Database.

I just wanted to inform you about this error so you may can fix it.

In that case you should probably discard the database.

The Doctor report shows many issues and is seems that the database file was indeed damaged and corrupted. Many different things can cause database corruption, including for example copying a database file while it is open, discarding the recovery file of a database, etc. but it would be impossible to know what was the cause in this specific case.

Thank you for this report.