Anybody seen these TADS 3 Workbench bugs?

I’m a fan of the TADS 3 Workbench, but after upgrading one of my old projects to TADS 3.1.3 and using the new Workbench, I found two really annoying problems.

I might report these on bugdb.tads.org/ later, but neither of them can be reproduced with a “minimal” example, so for now I just want to ask if anyone has seen these before.

Also, let me know if this is the best place for TADS 3 technical discussion. In the years since I last worked on TADS 3, rec.arts.int-fiction seems to have dried up.

1. Local variables and watch expressions become “corrupted”

See screenshots below for what I mean by “corrupted” local variables. Anybody seen this before?

When this problem happens, you can’t use primary features of the workbench. In the first screenshot, notice that the local variable “inputByteArray” is not only missing from the local variables list, but when I type it into the watch expressions, I get “undefined symbol,” even though it is in scope.

I encountered this in a rather large project I started many years ago, one that makes use of an extension I wrote called msg_custom.t, which replaces a substantial majority of the TADS 3 library messages. I found that when I removed this, the problem went away. But it’s not as simple as “there’s something wrong with my extension”; see (b) and © below.

A few things are unusual about this:
(a) I didn’t have this problem with previous versions of the Workbench (5-6 years ago).
(b) When I created an “ADV 3 Introductory” game and added msg_custom.t, the problem didn’t occur.
© When I tried including msg_custom.t in my large project but started commenting out various parts of it, I found there was not one specific part of the code that was the culprit. If I commented out a certain percentage of its code, the problem went away, regardless of which part of the file it was. If I commented out a smaller percentage, the problem would continue but would be less frequent.

2. Extremely long 90-second load times for projects with lots of resource files

When I started to use the TADS 3.1.3 version of the Workbench, I found my old project took a full 90 seconds to load, during which a Workbench popup would say “Loading Project… Restoring window layout…”

This was for a project where, within the .t3m file, within the “resource files” section, I was including about 20 folders that together contained 5700+ resource files (mostly small .png images). Eventually I figured out this was relevant; see (b) below.

Two things are unusual about this:
(a) I didn’t have this problem with previous versions of the Workbench (5-6 years ago).
(b) It’s a very black/white problem. The 90 seconds dropped to <2 seconds when I removed a stray .ini file that I had accidentally put in one of my resource folders. But then later the problem came back – 90 seconds again – this time for no apparent reason. Finally I moved all my resource folders into a .3r0 external resource file, and the problem has been gone ever since – essentially 0 seconds to load the project now.
tads3workbenchbug1a.png
tads3workbenchbug1b.png

Never seen anything like that. But those issues seem related to project size, and I don’t have very large projects.

Some (very random) ideas to try to circumscribe the issue further:

  • are you sure it’s related to the Workbench version rather than to the machine you are running it on? Did you have a different machine five years ago (a 32bit machine rather than a 64bit one maybe, assuming this has any relevance, which I don’t know) Did you try and observe the same problems on another machine?

  • your code involves byte arrays, and there exists a (different) bug involving byte arrays: bugdb.tads.org/view.php?id=240 Could both issues, though seemingly unrelated, have the same underlying cause?

I wish I could be of more help… these sorts of situations are tricky to figure out.

I have never seen these problems, but I don’t use nearly as many resource files, and the code I write is much less complex than yours.

But while we’re in the neighborhood of Workbench bugs, quite often when I start Workbench after I’ve been away for a few hours, when I go to run the game within Workbench I get a popup box with the message “VM Error:file not found.”

It’s easy to make the message go away - I only have to open any file, make a change, save it, and recompile. After that the message goes away… for a while. It’s a small inconvenience, but an annoying one.

Any thoughts?

–Bob

1 Like

Michel, thanks for the reply. The good thing is that neither of these issues is bothering me much anymore, now that I have workarounds for both of them. Also, the issues only seem to affect workbench debugging, not compilability, so I can still switch up my project later and build my game the way I want.

Thanks for mentioning the ByteArray bug, but I don’t think that’s it. The problem also exists when debugging other parts of my code.

Agreed, somehow the size of my project is what’s at issue. No, I didn’t try reproducing this on a different machine. I’ll try doing so. Then, if I succeed, I’ll post (at least in regards to #1) at the TADS 3 bug reporting site.

Bob, haven’t seen that one. I suppose it’s another minor annoyance with a workaround.

Changing the order of the source files in my build .t3m file fixed the debugger local variable corruption problem, at least for the code I wanted to debug. It probably will reappear if I try to put a breakpoint in something that’s further down the list of source files. I think this has something to do with the order of the files in the linker step.

My theory is that the “execution context” switcher in the debugger has a storage value that is too small (like 16-bit or 32-bit integer) and it can’t handle an object that is stored in a memory location greater than it’s size. Thus, the VM runs correctly and the local variables hold their correct values in the running process, but the debugger cannot display the local variables. When it switches execution context (like when you click on a something in the stack) it stores the new context pointer into a memory location that’s too small to hold it.

I’m running TADS on 64-bit Windows 10.

Another solution might be to release the debugger and all the libraries compiled for 64-bit Windows.

1 Like