Text difference, next 5.7.0, linux and Windows, for case 629

[geoffmcl]

Running regression tests using latest next tidy 5.7.0 on testbase next, version 5.5.84, gets a difference between linux message output, and windows message output, on one test, case 629... the html output are the same...

The windows tidy output exactly matches the testbase-expects, but the linux tidy seems to lose the first part of the string output...

Like for the first message the windows tidy correctly outputs, the expected -

Config: option "mute" given bad argument "FAKE_TAG" (STRING_ARGUMENT_BAD)

while linux tidy only outputs -

 (STRING_ARGUMENT_BAD)

And a similar problems with the next 4 message outputs... weird, very strange..

As indicated, the Windows Tidy passes 100%, while the Ubuntu linux Tidy fails on this one case, 629...

Have yet to dig deeply into it, but maybe somebody will spot either the problem, or maybe my testing problem, easily... thanks...

Am I doing something wrong in the testing,,, like picking up some stray config from somewhere, or something...

PS: My RPI Raspbian Tidy has the same missing output problem...

[geoffmcl]

PPS: And the same loss of output happens with release, master, tidy 5.6.0...

No chance yet to backup further, to see when this began...

Of course, have tried an earlier 5.5.31 so far, but it did not support the mute, and mute-id options, and also has no such message loss... will keep searching...

[balthisar]

I'll try to have a look...

[geoffmcl]

Back using tidy 5.7.0, running gdb with the config and html, with a Debug tidy...

Set break (gdb) break message.c:203 and then print cp shows me that only the message " (STRING_ARGUMENT_BAD)" is set, so it seems the problem is back when the message is constructed...

The same break point in MSVC shows the full message line... Hope this helps...

Will try to explore more, but am not very knowledgeable about gdb ...

[geoffmcl]

Seems vsnprintf, tmbstr.c:231 is failing in unix when the va_list args includes a string already in the output buffer... or something like that...

That is when doing -

        TY_(tmbsnprintf)(result->messageOutput, sizeMessageBuf, "%s (%s)",
         result->messageOutput, TY_(tidyErrorCodeAsKey)(code) );

Note the output buffer, result->messageOutput is also used as one of the inputs...

But would need to test that more... but off to bed now... HTH...

[geoffmcl]

The following patch works for me in Ubuntu -

diff --git a/src/messageobj.c b/src/messageobj.c
index 6f76152..7b9b415 100644
--- a/src/messageobj.c
+++ b/src/messageobj.c
@@ -158,8 +158,14 @@ static TidyMessageImpl *tidyMessageCreateInitV( TidyDocImpl *doc,
 
     if ( ( cfgBool(doc, TidyMuteShow) == yes ) && level <= TidyFatal )
     {
-        TY_(tmbsnprintf)(result->messageOutputDefault, sizeMessageBuf, "%s (%s)", result->messageOutputDefault, TY_(tidyErrorCodeAsKey)(code) );
-        TY_(tmbsnprintf)(result->messageOutput, sizeMessageBuf, "%s (%s)", result->messageOutput, TY_(tidyErrorCodeAsKey)(code) );
+        ctmbstr pc = TY_(tidyErrorCodeAsKey)(code);
+        i = TY_(tmbstrlen)(result->messageOutputDefault);
+        if (i < sizeMessageBuf)
+            TY_(tmbsnprintf)(result->messageOutputDefault+i, sizeMessageBuf-i, " (%s)", pc );
+        i = TY_(tmbstrlen)(result->messageOutput);
+        if (i < sizeMessageBuf)
+            TY_(tmbsnprintf)(result->messageOutput+i, sizeMessageBuf-i, " (%s)", pc );
+        i = 0;
     }
 
     result->allowMessage = yes;

So this does suggest a problem with vsnprinf at least in some linux implementations...

Not sure the guard if (i < sizeMessageBuf) is really required... what do you think?

[geoffmcl]

As can be seen, have moved this to the source repo, Issue 655 since this does not appear to be a regression tests update problem..