java.lang.OutOfMemoryError (single table)
Brought to you by:
johncurrier
Menu
▾
▴
#121 java.lang.OutOfMemoryError (single table)
Stack trace below:
Gathering schema details....Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.lang.reflect.Array.newArray(Native Method)
at java.lang.reflect.Array.newInstance(Array.java:52)
at oracle.jdbc.driver.BufferCache.get(BufferCache.java:226)
at oracle.jdbc.driver.PhysicalConnection.getCharBuffer(PhysicalConnection.java:7600)
at oracle.jdbc.driver.OracleStatement.prepareAccessors(OracleStatement.java:991)
at oracle.jdbc.driver.T4CTTIdcb.receiveCommon(T4CTTIdcb.java:273)
at oracle.jdbc.driver.T4CTTIdcb.receive(T4CTTIdcb.java:144)
at oracle.jdbc.driver.T4C8Oall.readDCB(T4C8Oall.java:806)
at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:355)
at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:191)
at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:523)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:207)
at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:863)
at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1153)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1275)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3576)
at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3620)
at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1491)
at oracle.jdbc.OracleDatabaseMetaData.keys_query(OracleDatabaseMetaData.java:3710)
at oracle.jdbc.OracleDatabaseMetaData.getImportedKeys(OracleDatabaseMetaData.java:3777)
at net.sourceforge.schemaspy.model.RemoteTable.connectForeignKeys(RemoteTable.java:55)
at net.sourceforge.schemaspy.model.Database.addRemoteTable(Database.java:746)
at net.sourceforge.schemaspy.model.Table.addForeignKey(Table.java:199)
at net.sourceforge.schemaspy.model.RemoteTable.connectForeignKeys(RemoteTable.java:60)
at net.sourceforge.schemaspy.model.Database.addRemoteTable(Database.java:746)
at net.sourceforge.schemaspy.model.Table.addForeignKey(Table.java:199)
at net.sourceforge.schemaspy.model.RemoteTable.connectForeignKeys(RemoteTable.java:60)
at net.sourceforge.schemaspy.model.Database.addRemoteTable(Database.java:746)
at net.sourceforge.schemaspy.model.Table.addForeignKey(Table.java:199)
at net.sourceforge.schemaspy.model.RemoteTable.connectForeignKeys(RemoteTable.java:60)
at net.sourceforge.schemaspy.model.Database.addRemoteTable(Database.java:746)
at net.sourceforge.schemaspy.model.Table.addForeignKey(Table.java:199)
Parameters used:
-t orathin -db MYDB-u MYUSER -p MYPASSWORD -o MYFOLDER -host someurl -schemas "schemaname" -port 1521 -noviews -i "(OFFENDING_TABLE)"
It looks like it is falling in some sort of infinite loop while analyzing (perhaps a badly built, self-referencing foreign key?). I cannot provide DDL information for the table since it is our vendor's propietary information.
I was able to run SchemaSpy successfuly for other tables
John,
I implemented a simple cycle checking algorithm that solved the particular error that I was experiencing.
I created an static array in Remote Table that keeps track of the last two FKs 'seen' by the connectForeign key method. If the hash of the second to last FK is identical to the current FK hash, then it breaks the loop.
Attached is my version. Is this solution acceptable?
Does swapping lines 746 and 747 of Database solve it? I.e. move remoteTables.put(...) before remoteTable.connectForeignKeys().
John
Yes! swapping lines 746 and 747 did the trick!
Thank you!
This is OT but I was wondering how do you debug child threads in Eclipse? I tried putting breakpoints on the connectForeigKeys method, but they were never hit by the debugger (I think perhaps because that code was run in one of the two child threads spawned). I haven't done much multithreading programming, so any pointers (book/link/article, etc..) would be appreciated
Glad that worked. I've committed that fix in rev 602.
As far as I know breakpoints in Eclipse should be hit by every thread. You can configure a specific breakpoint to only trigger on specific threads, but that's not the default. I'd try putting additional breakpoints in that area. The one you have might not be on a truly executable line of code, but in that case it should be rendered differently.
John
I was looking at the SVN log, and revision 602 is for a different bug.
Revision 603 makes reference to this bug, but does not show any changes to Database.java. It shows a change to MultipleSchemaAnalizer.java
Yea, I screwed that up a bit. It's in rev 604.
John