Community
Participate
Working Groups
Hello all, I am using Wikitext 1.9.0.20130621-1305 to convert from Mediawiki to HTML. With a certain piece of text, it gets stuck in a loop. I think the text is valid. Either way, I don't think it should get stuck in a loop forever. It comes from the Finnish Wikipedia page for "Dio". The problem is the following line: <!-- -->{{Yhtye/tietorivi|[[Universal Music Group]]}}<!-- -->{{Yhtye/tietorivi|Vertigo Records}} When the second "part" of the line is brought down onto its own line, it works fine. It also works fine as it is if it is the last line of the infobox. I have included a JUnit test which demonstrates the problem.
Created attachment 235587 [details] JUnit test which currently fails
Thanks for the bug Calum. Can you add the specific JVM version that you're using to this bug? Sometimes that makes a difference since we're using regular expressions.
Hey David, JDK 1.6.0_25 seems to be what Eclipse is configured to run currently. java version "1.6.0_25" Java(TM) SE Runtime Environment (build 1.6.0_25-b06) Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode) It looks like the Oracle JDK, which is strange, as I'd usually use the OpenJDK one. I have this file in my Downloads, which must be what I used. jdk-6u25-linux-x64.bin I think I had a problem in the OpenJDK one a while ago, and perhaps I switched to the Oracle one to resolve it. I followed the code looping around, and it didn't seem to be to do with regex - but I didn't look too deeply. Calum
Reduced example: public void testParserShouldNotTimeout() { String input = "<!-- X -->Lorem<!-- Y -->Ipsum\n" + "<!-- Z -->"; String html = parser.parseToHtml(input); TestUtil.println(html); assertTrue(html.contains("XXX")); //TODO fix the assert. } Added in class MediaWikiLanguageTest. The assertTrue(..) line is never executed. I will try to debug it this evening, to see what is going wrong.
Here a Gerrit Change with the proposed JUnit test and a solution: https://git.eclipse.org/r/17659 It does the job but I am not sure this is the solution. Two questions: 1/ Are you sure that CommentBlock should be the ParagraphBreakingBlocks? Why is there a NESTED_BLOCK_START_PATTERN after the ParagraphBreakingBlocks Check? I wanted to have a look with a Code Coverage tool, because I do not see when this code is used. 2/ Are you sure that findCloseOffset can return -1? It seems to me, that by returning -1, the ParagraphBlock instance is never poped from the nestedBlocks stack. => Maybe with an other value, my change in canResume(..) would not be necessary.
Jeremie, thanks for your excellent work. I've pushed an updated patchset to the review that includes your test but provides an alternate solution. Please take a look and let me know what you think.
Keeping closed blocks in nestedBlocks is wrong. Your solution that pop them from the stack is good. I still think that the nested-protocol in MediaWiki ParagraphBlock is not so well implemented: findCloseOffset(..) should not always return -1. Your change makes MarkupLanguage more robust -> this is good.
I've merged review 17659, thanks Jeremie. Calumn I'll close this one as resolved/fixed since the change fixes the problem in our tests. If you can confirm that the fix works for you that would be great. Feel free to reopen this bug if the problem comes up again.
*** Bug 402248 has been marked as a duplicate of this bug. ***
