#132 Error in skeleton.nested

[ronald]

Hi Steve, hi Gerwin,

using the skeleton.nested, the resulting program showed the following behaviour:

echo "list sessions;" | sdmsh

hangs forever. But

echo "list sessions;" > /tmp/x
sdmsh < /tmp/x

teminates as should be.

After merging the skeleton.default and skeleton.nested this erroneous behaviour vanished.

Diffing the old and new skeleton.nested shows (< == new; > == old):

[ronald@cheetah shell]$ diff skeleton.nested* | more
39c39
< 
---
>   
169c169
<     while (numRead == 0) { // bug #130 discussion; while is better than if
---
>     if (numRead == 0) {
403,409d402
<     // cached fields:
<     int zzCurrentPosL;
<     int zzMarkedPosL;
<     int zzEndReadL = zzEndRead;
<     char [] zzBufferL = zzBuffer;
<     char [] zzCMapL = ZZ_CMAP;
< 
413c406,411
<       zzMarkedPosL = zzMarkedPos;
---
>       // cached fields:
>       int zzCurrentPosL;
>       int zzMarkedPosL = zzMarkedPos;
>       int zzEndReadL = zzEndRead;
>       char [] zzBufferL = zzBuffer;
>       char [] zzCMapL = ZZ_CMAP;

The HUGE difference is that the variables (notably zzEndReadL) aren't initialized by skeleton.default in every iteration of the while loop.

During the merge I wondered why there are two skeletons in the first place. Those who don't want to read from multiple streams just don't call yypushStream() and friends. One skeleton would be more than enough (and a link for backward compatibility).

for the sake of completeness I attached the new skeleton.nested.

Regards,

Ronald

[ronald]

small add-on.

Today I tried to write a minimal "working" example. So far I didn't succeed, unfortunately. It was even so, that our software seemed to work as intended, regardless of the skeleton used.
After a complete recompile, the software failed again, blocking as described.
Odd enought, it now also blocks when using a file as input. (Actually I think the original behaviour is stranger than the actual behaviour. The use of "odd" refers to the fact that a system behaves differently after a recompile of unchanged sources).
There's no difference in behaviour between the two skeletons any more (the original and the patched version).

It's all very weird. I'll do some more investigations. If I get any results, I'll report them. In the mean time I accept this to be a low priority bug, as everything works flawlessly with jflex 1.4.x

[ronald]

For the record, the relevant part of jstack output:

"main" prio=10 tid=0x00007f9cfc009000 nid=0x1b29 runnable [0x00007f9d002df000]
   java.lang.Thread.State: RUNNABLE
    at java.io.FileInputStream.readBytes(Native Method)
    at java.io.FileInputStream.read(FileInputStream.java:272)
    at java.io.BufferedInputStream.read1(BufferedInputStream.java:273)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:334)

    - locked <0x0000000688c3cf70> (a java.io.BufferedInputStream)
    at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283)
    at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325)
    at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177)
    - locked <0x0000000688a06ce8> (a java.io.InputStreamReader)
    at java.io.InputStreamReader.read(InputStreamReader.java:184)
    at de.independit.scheduler.shell.MiniScanner.zzRefill(MiniScanner.java:648)
    at de.independit.scheduler.shell.MiniScanner.yylex(MiniScanner.java:982)
    at de.independit.scheduler.shell.MiniScanner.advance(MiniScanner.java:523)
    at de.independit.scheduler.shell.MiniParser.yyparse(MiniParser.java:832)
    at de.independit.scheduler.sdmsh.go(sdmsh.java:196)
    at de.independit.scheduler.SDMSApp.App.doTry(App.java:325)
    at de.independit.scheduler.SDMSApp.App.reTry(App.java:349)
    at de.independit.scheduler.SDMSApp.App.run(App.java:440)
    at de.independit.scheduler.sdmsh.main(sdmsh.java:215)

[ronald]

My next attempt to build a minimal working example has been a bit more successful. Attached are:

1. the jflex file (AReader.jlex)
2. the jflex 1.7 output (AReader.java.1.7)
3. the jflex 1.4 output using the same 1.7 skeleton (AReader.java.1.4)

after a

cp AReader.java.1.4 AReader.java
javac AReader.java

resp.

cp AReader.java.1.7 AReader.java
javac AReader.java

the following test shows the difference:

echo "some text no matter what but ending with semicolon;" | java AReader

The 1.7 version hangs, the 1.4 version doesn't.
Obviously the title of the bug is wrong. Sorry for that.
I'll continue to investigate the matter, but would gratefully accept any help.

Although this source code works flawlessly since years, I don't exclude the possibility of a small flaw in my jflex code. The fact that the 1.4 version requires two "^D" to terminate might be a clue here.

The java version I'm using is

[ronald@cheetah shell]$ java -version
java version "1.7.0_65"
OpenJDK Runtime Environment (rhel-2.5.1.2.el6_5-x86_64 u65-b17)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)