permaculture playing cards*
The moose likes Java in General and the fly likes Bug in Suns 1.6 server VM (I think) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Bug in Suns 1.6 server VM (I think)" Watch "Bug in Suns 1.6 server VM (I think)" New topic
Author

Bug in Suns 1.6 server VM (I think)

Darryl Nortje
Ranch Hand

Joined: Jun 11, 2002
Posts: 140
Howzit guys.

I thought I would first come check here before logging a bug with sun, and to find out how to log a bug with sun. But I think I have found a bug in the Server VM of jdk1.6 (update 10, 11 and 12) haven't checked the rest.

Please can you guys help with ideas for further testing, as well as perhaps a solution, if this is not a bug. Thanks.

We recently upgraded from 1.5 to 1.6u10. On our dev boxes the default vm that the JRE picks up is Client. On our test and prod servers the default is Server. Everything worked fine in 1.5, both server and client VM's.

When we upgraded we suddenly started getting errors in test and prod, that were not reproducable in dev. After lots and lots of attempts to change the code I eventually forced the test server to use the client VM by default by changing values in the jvm.cfg file in jre/lib/i386 directory. And suddenly Test stopped breaking. Same for prod.

So, here is the code, it's very simple. We're calling a stored procdure running on AS400 database (DB2 variant) and after a set amount of calls, we start getting data integrity errors. Please don't forget that this code worked as is on 1.5, on the server VM. The error in question, with a particular set of values passed into the call is

java.sql.SQLException: [CEE9901] Application error. MCH1202 unmonitored by FEMEMSP at statement 0000000108, instruction X'0000'.

And this error gets thrown on the 46th time that I call this stored proc, in the loop, and everytime on the 46th time. 45 times it works perfectly and returns the expected results. So here is the code, and the full stack trace.

We've updated to the latest jdk update, the latest jdbc drivers, (jtopen 6.4) I've put finally blocks in to release all resources after each iteration, I've tried everything I can think of, to get this thing to work, but to no avail.



It's a bit long, but this generates the error. Attached for completeness is the stored procedure, not that it should make a difference because, like i said, it worked perfectly on 1.5.

Here is the stack trace.

java.sql.SQLException: [CEE9901] Application error. MCH1202 unmonitored by FEMEMSP at statement 0000000108, instruction X'0000'.
at com.ibm.as400.access.JDError.throwSQLException(JDError.java:650)
at com.ibm.as400.access.JDError.throwSQLException(JDError.java:621)
at com.ibm.as400.access.AS400JDBCStatement.commonExecute(AS400JDBCStatement.java:915)
at com.ibm.as400.access.AS400JDBCPreparedStatement.executeQuery(AS400JDBCPreparedStatement.java:1111)
at vmbug.VMBugTester.main(VMBugTester.java:76)



Then I changed the value of the date field (defined above). I gave it a value, any old value. The stored proc now returned no results, but executed fine. This time however, it executed 48 times before getting an error, and always 48 times, here is that error / stack trace.

java.sql.SQLException: [SQL0180] Syntax of date, time, or timestamp value not valid.
at com.ibm.as400.access.JDError.throwSQLException(JDError.java:650)
at com.ibm.as400.access.JDError.throwSQLException(JDError.java:621)
at com.ibm.as400.access.AS400JDBCStatement.commonExecute(AS400JDBCStatement.java:915)
at com.ibm.as400.access.AS400JDBCPreparedStatement.executeQuery(AS400JDBCPreparedStatement.java:1111)


If I run this program using the client VM, both instances work and never fall over with this error. So it looks to me like something is wrong with the Server VM...





Ok, that's that. Anyone have any ideas what might be causing this type of behaviour, or help me with the place/link to log the bug with Sun.

Thanks
cheers
Darryl

PS:
No attachment, I get the error

Files with the extension .zip are not allowed as attachment in the message.
or .txt, or .cfg or no extension.
What extensions are allowed.
Martijn Verburg
author
Bartender

Joined: Jun 24, 2003
Posts: 3274
    
    5

I think you've covered a majority of reasonable test scenarios, I'd post this a bug to Sun.


Cheers, Martijn - Blog,
Twitter, PCGen, Ikasan, My The Well-Grounded Java Developer book!,
My start-up.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19541
    
  16

The exceptions seem to indicate the error is in the database driver, not the JVM. But that does not explain why the same code with the same database driver does work in the client VM.

Can you perhaps upgrade the database driver, to see if that fixes the issue? Perhaps it's simply incompatible with the 1.6 server VM.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Martijn Verburg
author
Bartender

Joined: Jun 24, 2003
Posts: 3274
    
    5

Hi Rob, I was thinking the same thing, but I think he mentions in his post that he has upgraded the drivers to the latest version..
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Bug in Suns 1.6 server VM (I think)
 
Similar Threads
object required in java script error
Close JDialog without hide
PreparedStatement on AS400
Problem with XA Transactions in JBoss when use multiple datasources for related tables
SQL built-in functions in PreparedStatement?