Re: Any suggestions on debugging assertion fail in Lua testsuite, in a custom Lua port?

[Mateusz Czaplinski <czapkofan@...>]

On Thu, May 31, 2012 at 3:57 PM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> I'm trying to pursue porting Lua to Go language's C compiler[1], and
>> currently I'm stuck at an error in the Lua testsuite, in "gc.lua" -
>> console output looks like this:
>>
>>     testing garbage collection
>>     tables
>>     strings
>>     functions
>>     functions with errors
>>     long strings
>>     ---
>>     pre:    194
>>     stop:   59
>>     peak:   71
>>     after:  62
>>     result: 1
>>     PANIC: unprotected error in call to Lua API ([string "from
>> loadbuffer"]:117: assertion failed!)
>>
>> [...]
>>
>> The line number 117 is in slightly modified source, so it should be
>> understood as line 111 in original "gc.lua", i.e.:
>>
>>     assert(dosteps(0) > 10)
>
> I have no idea about the unprotected error, but please note that the
> above assert is highly dependent on many things and probably does
> not hold for different Lua implementations.

The "unprotected error" fragment of the line is not important;
probably I should have edited the line in the transcript to avoid
confusion, and make it look like:

    [string "from loadbuffer"]:117: assertion failed!

As to the statement that the assert might not hold for different
implementations - thanks, then there's a chance it might be the
reason. *But*... I still do feel uneasy and in doubt about it in this
particular case; the matter is, that this actually is not a different
implementation - it's the canonical Lua 5.1 C implementation; it
should be probably best looked at as an effort to port it to a yet
another machine+compiler. The differences in my "port" are that:

  * it's compiled with yet another (reportedly) ANSI C compatible
compiler (belonging to the Go compilers suite, transplanted from
Plan9, but these are I believe rather irrelevant details here),
  * it uses custom implementation of Standard C Library (with some
lurking bugs expected),
  * all #if defined(...) blocks were manually preprocessed,
  * luaconf.h was modified where it is expected to be modified, in
order to prepare it to a somewhat nontypical runtime environment where
it needs to run.

Therefore (while admitting I don't know anything about the Lua's GC
algorithm), as the GC's code is exactly the same, I'd most expect it
to run identical or nearly identical as the original (maybe with some
slight differences because of possibly different struct packing
approach and/or a few sizeofs). So, is this line expected to show a
different behaviour when porting Lua to a new compiler + some weird
OS, but still on x86? You wrote that it is "highly dependent on many
things", so I now understand the answer may still be "yes", but I'd be
very grateful if you could possibly answer taking into account the
more detailed description I tried to put up here.

Thanks a lot for the response already however, as it made me worry a
bit less about this problem for now; I will therefore probably focus
on the rest of the testsuite first, before maybe coming back to the
issue afterwards.

Thanks and Regards
/Mateusz Czapliński.