• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Bug in Suns 1.6 server VM (I think)

 
Ranch Hand
Posts: 140
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 3285
13
Mac OS X Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think you've covered a majority of reasonable test scenarios, I'd post this a bug to Sun.
 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Martijn Verburg
author
Posts: 3285
13
Mac OS X Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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..
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic