[ http://issues.apache.org/jira/browse/DERBY-1222?page=comments#action_12374661 ]
Myrna van Lunteren commented on DERBY-1222: ------------------------------------------- This is not a test specific issue; I can see a problem when I run with just ij. The problem is reproduced easily by doing the following on os/390 - zOS: java -Dderby.ui.codeset=EUC_JP org.apache.derby.tools.ij [gobbligook removed for jira] connect 'jdbc:derby:tstdb;create=true'; [gobbligook removed for jira] create table t1 (c1 int); ...tons and tons and tons of more gobbligook. The first bits of gobbligook are apparently what the ij prompt looks like when you try to do a derby.ui.codeset of EUC_JP on a system that normally has default encoding of Cp1047. >From various native2ascii experiments, it turns out what is returned in a >loopy way (i.e. it apparently loops forever until the process is killed, >gobbling up resources on the machine as it goes) is: ij > IJ ERROR: IOException: null There is no stack trace, because I have to kill the process. When I first tested this test with version 10.1.1.0 on this platform, I did not have the changes for DERBY-658 in place, so I had to convert the files using native2ascii -encoding Cp1047 -reverse but it looks like that did not work and the file UnicodeEscape_JP.sql actually never got converted and the test failed with a FileNotFound exception from the harness. So this may not be a regression per se. I could convert the UnicodeEscape_JP.sql file this time, however. Either way I think the looping is worrysome. > test i18n/UnicodeEscape_JP.sql appears to hang on ibm15 z/OS. > ------------------------------------------------------------- > > Key: DERBY-1222 > URL: http://issues.apache.org/jira/browse/DERBY-1222 > Project: Derby > Type: Bug > Versions: 10.1.2.4 > Environment: zOS > Reporter: Myrna van Lunteren > > The test i18n/UnicodeEscape.sql appears to hang on z/OS with ibm15, both > latest builds of 10.1 and 10.2. > The test only takes about 3 seconds on a (fast) linux box, but I've had it > sit for hours - i.e. past the 1 hour time out of the test harness - on zOS. > When I finally kill the ij process kicked off by the test, the system shows > indications of major stress, like javacore, and heapdumps, and OutOfMemory > errors. Not sure that the OutOfMemory is caused by the whatever trouble is > brewing, or that the trouble is caused by the OutOfMemory... > This could be a test issue or test harness issue, needs further research. > This happens both with ibm14 and ibm15, with the patch for 658, both 10.1.2.4 > and 10.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
