You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Myrna van Lunteren (JIRA)" <de...@db.apache.org> on 2006/04/16 02:11:01 UTC
[jira] Commented: (DERBY-1222) test i18n/UnicodeEscape_JP.sql
appears to hang on ibm15 z/OS.
[ 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