Segmentation fault with Linux t3make and adv3Lite

with adv3Lite, both 1.5 and 1.4 this segfault error happens:

symbol_export …/adv3Lite/english/english.t -> obj/english.t3s
symbol_export …/adv3Lite/english/grammar.t -> obj/grammar.t3s
Errore di segmentazione

symbol_export …/oldlib/1.4/english/english.t -> obj/english.t3s
symbol_export …/oldlib/1.4/english/grammar.t -> obj/grammar.t3s
Errore di segmentazione

(“errore di segmentazione” is “segmentation fault” in Italian)

the relevant .t3m:

[code]-D LANGUAGE=english
-Fy obj
-Fo obj
-v
-w1

##sources
-lib system
-lib …/adv3Lite/adv3Lite
#-lib …/oldlib/1.4/adv3Lite
-source start
[/code]

I’m missing/overlooking something ? any thoughts ?

Best regards from Italy,
dott. Piergiorgio.

Have you tried building the latest code from GitHub? Lots of crashes are fixed there.

tried, with the same identical results. (I used the “next” branch)

Best regards from Italy,
dott. Piergiorgio.

A year later, this problem is still around here… Any new (or less new…) idea ?

(yes, I’m through checking the state of IF compilers & tools here…)

Best regards from Italy, and sorry for the bump.
Dott. Piergiorgio.

@Piergiorgio_d_errico

It turns out this is a known but yet unresolved bug. I’m not sure yet if the following is an actual fix or just some band-aid that hides the real problem, which is why I didn’t push it to the repo. I need to run TADS base code changes though Mike Roberts, but he didn’t have time to deal with this yet.

If you want to test this out, open the tads3/tcprs.cpp file and at line 1044 you will find this:

CTcPrsNode *CTcParser::create_sym_node(const textchar_t *sym, size_t sym_len)

Replace that whole function with the following and rebuild t3make (make t3make should be enough in this case):

/*
 *   Create a symbol node 
 */
CTcPrsNode *CTcParser::create_sym_node(const textchar_t *sym, size_t sym_len)
{
    /* 
     *   First, look up the symbol in local scope.  Local scope symbols
     *   can always be resolved during parsing, because the language
     *   requires that local scope items be declared before their first
     *   use. 
     */
    if (local_symtab_ != 0) {
        CTcPrsSymtab *symtab;
        CTcSymbol *entry = local_symtab_->find(sym, sym_len, &symtab);

        /* if we found it in local scope, return a resolved symbol node */
        if (entry != 0 && symtab != global_symtab_)
            return new CTPNSymResolved(entry);
    }

    /* if there's a debugger local scope, look it up there */
    if (debug_symtab_ != 0)
    {
        /* look it up in the debug symbol table */
        tcprsdbg_sym_info info;
        if (debug_symtab_->find_symbol(sym, sym_len, &info))
        {
            /* found it - return a debugger local variable */
            return new CTPNSymDebugLocal(&info);
        }
    }

    /* 
     *   We didn't find it in local scope, so the symbol cannot be resolved
     *   until code generation - return an unresolved symbol node.  Note a
     *   possible implicit self-reference, since this could be a property of
     *   'self'.  
     */
    set_self_referenced(TRUE);
    return new CTPNSym(sym, sym_len);
}

Another year later… and the problem persists:

TADS Compiler 3.1.3 Copyright 1999, 2012 Michael J. Roberts
Files to build: 100
symbol_export /usr/local/share/frobtads/tads3/lib/_main.t -> obj/_main.t3s
symbol_export /usr/local/share/frobtads/tads3/lib/file.t -> obj/file.t3s
[…]
symbol_export …/a3lite/thoughts.t -> obj/thoughts.t3s
symbol_export …/a3lite/english/english.t -> obj/english.t3s
symbol_export …/a3lite/english/grammar.t -> obj/grammar.t3s
Errore di segmentazione
^------ segmentation fault in Italian, from Linux

News on this issue ?

Best regards from Italy

Did you test the modification I posted last year to see if it fixes the issue?

Is what I have dedicated my afternoon and night, after a cooldown from tackling the year-old issue. Indeed work, but with really strange results (smaller binaries when built with -d (debug), both with standard adv3 and adv3lite a very anomalous thing I’m still investigating)

Currently I consider unpatched TADS3/standard adv3 as “production grade” and patched TADS3/adv3lite as “experimental”. (I have patched your current github frobTADS, last commit 13 June this year)

Thanks and best regards from Italy,
dott. Piergiorgio.

@Piergiorgio_d_errico

Can you test a different patch? I pushed it to the fix-null-local-symbol-table-lookup branch, so just fetch and checkout that one.

Does this also fix the issue?

cmake … fails:

CMake Error at CMFrob.cmake:189 (install):
install TARGETS given no RUNTIME DESTINATION for executable target “frob”.
Call Stack (most recent call first):
CMakeLists.txt:206 (include)

CMake Error at CMT2Compiler.cmake:33 (install):
install TARGETS given no RUNTIME DESTINATION for executable target “tadsc”.
Call Stack (most recent call first):
CMakeLists.txt:210 (include)

CMake Error at CMT3Compiler.cmake:38 (install):
install TARGETS given no RUNTIME DESTINATION for executable target
“t3make”.
Call Stack (most recent call first):
CMakeLists.txt:214 (include)

– Configuring incomplete, errors occurred!

I strongly suspect is related to the other commit in that branch:

https://github.com/realnc/frobtads/commit/90bb42fce2c94724dc15a5b5044113e9dd5a5aba

do you want me to try reverting the cmake-related files to the prior master version (a simple backup of the branch files followed by a cp -a of the cmake-related files from the master dir) ?

[BTW, I have decided to NOT entry this year’s IFComp, so I have IF-dev time available…]

Best regards from Italy,
dott. Piergiorgio.

Looks like older cmake versions still need a DESTINATION specified for executables. Fixed in all branches and rebased the fix-null-local-symbol-table-lookup branch and force-pushed it. So make sure to

git fetch

first, then

git checkout fix-null-local-symbol-table-lookup

and then

git reset --hard origin/fix-null-local-symbol-table-lookup

Done as you suggested, the results was the very same:

/if/wrk/tads3/tsta3lit$ ls -l start.t*
-rw-r--r-- 1 pigi pigi     962 mag  5  2013 start.t
-rw-r--r-- 1 pigi pigi 1555281 ago 30 13:45 start.t3.aug30
-rw-r--r-- 1 pigi pigi 1117930 ago 30 13:46 start.t3.aug30.debug
-rw-r--r-- 1 pigi pigi 1555281 ago 25 21:20 start.t3.bak

FYI, my cmake is

cmake -version
cmake version 3.13.4

CMake suite maintained and supported by Kitware (kitware.com/cmake).

HTH and
Best regards from Italy,
dott. Piergiorgio.

That’s quite normal. You need to use -d -pre instead of just -d, because pre-initialization is not performed by default in debug builds like it is in release builds. Or the other way around, use -nopre when doing a release build to prevent pre-init. That way you’re not comparing apples to oranges.

1 Like

thanks. Now story file sizes make sense:

-rw-r--r-- 1 pigi pigi 1555281 ago 30 13:45 start.t3.aug30
-rw-r--r-- 1 pigi pigi 1117930 ago 30 13:46 start.t3.aug30.debug
-rw-r--r-- 1 pigi pigi  600709 ago 31 13:05 start.t3.aug31
-rw-r--r-- 1 pigi pigi 2253801 ago 31 13:03 start.t3.aug31.debug
-rw-r--r-- 1 pigi pigi 1555281 ago 25 21:20 start.t3.bak

for the record, the .aug31 story file was compiled with this command:

…/t3mak0830 -nopre -f test.t3m

and the corresponding debug story file is compiled with:

…/t3mak0830 -d -pre -f test.t3m

last thing, the relevant test.t3m:

-D LANGUAGE=english
-Fy obj
-Fo obj
-w1

##sources
-lib system
-lib ../a3lite/adv3Lite
-source start

I’ll do some more testing, involving also the standard adv3 library, then, if successful, the patched “fix-null-local-symbol-table-lookup” build (the …/t3mak0830 above) will be installed, as t3make, into /usr/local/lib and promoted to “production” status; anyway, your final suggestion, the one about switches, gets the deserved “solution” flag. Thanks, kudos and

Best regards from Italy,
dott. Piergiorgio.

1 Like

Thanks for testing! If nothing else pops up, I’ll merge the fix for the next release.

1 Like

indeed something has popped up: with adv3 all works as expected with -nopre, with adv3lite, the -nopre story files simply don’t run, all four 'terps (frob, qtads2, qtads3 and gargoyle tadsr) giving

Runtime error: nil object reference
[Hit any key to exit.]

summing all up, my diagnosis is what seems NOT production-grade is adv3lite… but I’m reasonably sure that adv3 works as expected (and -nopre under adv3 giving avg ~50-60k smaller story files…)

Best regards from Italy,
dott. Piergiorgio.

That issue was there before. You just couldn’t actually encounter it because of the t3make crash :slight_smile:

Not a real problem. the actual one, now solved, was the capability of experimenting and fooling with adv3lite; if something there has general usefulness, perhaps I’ll attempt to implement/port it as an adv3 extension.

I guess that you can safely merge the fix, with an proviso in the documentation (in the changelog, perhaps ?) about the much larger (doubled in size) story files generated by adv3lite.

I guess we have closed the issue, or you want me to do some specific tests ?

Thanks again, and
Best regards from Italy,
dott. Piergiorgio.