db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1222) test i18n/UnicodeEscape_JP.sql appears to hang on ibm15 z/OS.
Date Sun, 16 Apr 2006 00:11:01 GMT
    [ 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 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:
>  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 and 10.2.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message