#78 eclipse freeze, out of memory error

[arndt_t]

Hello,

with the following code it is possible to reproduce this error:
- change elsif to "else if" AND remove the colon after testsig <= '0';
- If you are moving the mouse out of the veditor frame or move to the error marker col.:
--> CPU goes to full load (50% in case of DualCore) and the memory grows till the Crash is reached

---------------------

ARCHITECTURE rtl OF test IS
signal testsig : bit;
BEGIN
process
begin
if (now < 5 ms) then
testsig <= '1';
elsif (now > 5 ms) then
testsig <= '0';
end if;
wait for testsig;
end process;
END rtl;

---------------------
Environment:
Windows XP -> Eclipse 3.4.2, Veditor 0.7

[arndt_t]

[KOBAYASHI Tadashi]

It seems that the error recovery in VHDL parser doesn't work.

I tried to modify "error_skipto" method in vhdl.jjt. Maybe I can avoid the bug.
--------------------------------------------------------------
JAVACODE void error_skipto(int kind, String message)
{
errs.Error(message,null);
Token t;
Token prev = null;
do
{
t = getNextToken();
if (prev != null && prev.beginLine == t.beginLine && prev.beginColumn == t.beginColumn)
break;
prev = t;
} while ((t.kind != kind));
}
--------------------------------------------------------------
The problem is that getNextToken returns same token in "unexpected EOF" status. So I added a check code to test getNextToken returns same position in the file continuously.

I don't think it is the best solution. If anyone know better, please follow comment.

[KOBAYASHI Tadashi]

There are any other bugs about VHDL parser. My proposal cannot fix them.

I received the better solution by mail. It is the "timeout method".
When the parser hasn't finished after 2 seconds, the parser thread is stopped.
I will commit new code.

[aghoras]

tadashi is was on the write path. I ran into this problem when I tried to improve the time-out technique without using the thread_stop. The problem is caused by "while ((t.kind != kind)) " line of the error_skipto function. During error recovery, the parser tries to look for the next token so it can start parsing again. But if the token is not found, then getNextToken will get called repeatedly eventhough the end of the file is reached. So I changed the line to read;
while ((t.kind != kind) && t.next != null);

It seems to fix the problem.