Recursive user keywords can break the whole test execution

[GoogleCodeExporter]

When testing dry-run (issue 541) we noticed that recursive user keywords
can crash the whole test execution or creating logs/reports can fail. This
kind of breakage isn't good even when the situation is caused by a user error.

Original issue reported on code.google.com by pekka.klarck on 12 May 2010 at 6:28

[GoogleCodeExporter]

We discussed about this and there is not much we can do. The biggest problem is 
to
know how much recursion is too much? Of course we could try to handle the 
exception
caused by the recursion, but the real value is anyway missing.

Original comment by jpran...@gmail.com on 28 May 2010 at 7:09

• Changed state: WontFix
• Added labels: Target-2.6
• Removed labels: Target-2.5

[GoogleCodeExporter]

One option to solve this problem is to check whether interpreter is going to 
raise
maximum recursion depth exception and act before that is raised. This could be
checked with inspect.stack() and sys.getrecursionlimit(). However, inspect stack
seems to be quite slow in this case.

Original comment by jpran...@gmail.com on 28 May 2010 at 10:59

• Changed state: Accepted
• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Note that if you want to call a library keyword with the same name as the user 
keyword from that user keyword, you need to prefix the keyword with the library 
name. For example, if I have keyword `Do X` in a library `MyLib`, I can use it 
from a user keyword `Do X` like this:

Do X  [Arguments]  ${arg}
  Log  Got arg ${arg}
  MyLib.Do X  ${arg}

Original comment by pekka.klarck on 23 Jul 2010 at 9:14

[GoogleCodeExporter]

Initially descoped from 2.6 and moved to 2.7.

Original comment by janne.t....@gmail.com on 3 May 2011 at 9:09

• Added labels: Target-2.7

[GoogleCodeExporter]

This is actually pretty simple to fix: we just need to keep count on how many 
user keywords are open and fail the keyword if that number exceeds certain 
limit.

I have a fix where the limit is 100 ready but I want to create tests before 
committing it. First it's time to go to the bed, though.

Original comment by pekka.klarck on 19 Dec 2011 at 11:27

[GoogleCodeExporter]

This issue was updated by revision 24c720921b9f.

The infinite recursion problem is now fixed and also acceptance
tested. There is a hard limit of 100 keywords that can be open
simultaneously. That ought to be enough for all valid usages so I
don't consider the fix backwards-incompatible. I also decided to raise
the priority of this issue as crashes are always somewhat nasty and
this has happened several times in real life.

Notice that before the simple fix prevented recursion involving Run
Keyword variants, a separate refactoring was needed to make them use
the same execution context as other keywords.

Original comment by pekka.klarck on 20 Dec 2011 at 10:50

• Changed state: Done
• Added labels: Priority-Medium
• Removed labels: Priority-Low

[GoogleCodeExporter]

Original comment by pekka.klarck on 12 Jan 2012 at 9:29

• Added labels: alpha1

[GoogleCodeExporter]

The hard limit of keywords that can be open has been dropped to 42 because 
higher values didn't work with Jython on Windows. If I remember correctly, that 
was done already in 2.7.

Original comment by pekka.klarck on 2 Jan 2013 at 8:10

[GoogleCodeExporter]

Recursion detection didn't work correctly with for loops (issue 1321).

Original comment by pekka.klarck on 2 Jan 2013 at 8:23