Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

infinite loop translating bizarre compound #70

Open
mk270 opened this issue Oct 30, 2016 · 9 comments
Open

infinite loop translating bizarre compound #70

mk270 opened this issue Oct 30, 2016 · 9 comments
Labels

Comments

@mk270
Copy link
Owner

mk270 commented Oct 30, 2016

The word "bestiasviginti" gets WORDS into an infinite loop, apparently.

@ids1024
Copy link
Contributor

ids1024 commented Oct 30, 2016

It seems to be stuck in this loop.

It also seems to be an issue with Whitaker's last release as well, and not an issue we added.

@mk270
Copy link
Owner Author

mk270 commented Oct 30, 2016

Hmm, a loop whose termination condition is also the loop invariant ...

@ids1024
Copy link
Contributor

ids1024 commented Nov 6, 2016

Do you have any idea what this loop is meant to achieve? Clearly Jj was meant to be modified in the body of the loop; otherwise I'm not sure.

If not, it's probably best to comment out the loop and add a line FIXME Figure out what this was meant to do and fix it or similar. Clearly the loop is never being entered except in cases like this where it causes an infinite loop.

This specific word seems to parse fine with the loop removed.

@mk270
Copy link
Owner Author

mk270 commented Nov 6, 2016

The loop is apparently never entered during the test cases, which involve translating a very long, badly formatted chunk of the Aeneid. Therefore it's very much a corner case. It may be that other varieties of Latin, e.g., church Latin, mediaeval Latin or whatever, or some non-default configuration choices lead to triggering the bug, but my hunch is it's exposed by a weird condition only true for very un-Latin-like input.

My instinct here is that we should throw an informatively-worded exception admitting that it's an internal programming error, and fix the underlying bug later. That will get rid of the infinite loop behaviour in the short term, which is a problem for code which wraps WORDS, without covering up other misbehaviours that may be more serious.

@mk270
Copy link
Owner Author

mk270 commented Nov 6, 2016

Incidentally, @ids1024 , did you find the place it was failing with gdb, or some other tool?

@ids1024
Copy link
Contributor

ids1024 commented Nov 6, 2016

I used gdb. I just built words with debugging symbols, triggered the issue, and hit ctrl-c which stopped it and printed the line it was on.

@ids1024
Copy link
Contributor

ids1024 commented Nov 6, 2016

@mk270 Where did you come across this word anyway?

@mk270
Copy link
Owner Author

mk270 commented Nov 6, 2016

The CGI version of WORDS had got into a busy loop, and the offending word was in its argv, and in the HTTP logs. There ensued some paranoid speculation about how on earth anyone had found such a word. It turns out to be a cut-n-paste error from some online Latin course.

@mk270
Copy link
Owner Author

mk270 commented Nov 6, 2016

I have a trivial patch which throws a bespoke exception.

mk270 added a commit that referenced this issue Nov 6, 2016
@mk270 mk270 added the bug label Aug 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants