A gosub that never returns

[Claire_CJS]

I think I’ve run into this before, but just.. HOW HOW HOW HOW can execution end when i return from a gosub, and not continue to the next line of a .BTM?

Literally, with echo on:

iff "1" != "%QUICK_LRC_MODE%" then                       
        gosub refresh_current_lyric_provider_metadatas   
endiff                                                   
echo "done 444"

I see the gosub. I see it return from the gosub. And the “echo done 444" line (and all future lines) simply DON’T EXECUTE.

I even got suspicious of the fact that iff behaves different from if, and tried doing something reductive and changing it to:

if "1" == "%QUICK_LRC_MODE%"  goto :skip_the_refresh_234
gosub refresh_current_lyric_provider_metadatas
:skip_the_refresh_234
echo "done 444"

It still never comes back. Every line of the subroutine refresh_current_lyric_provider_metadatas excutes just fine. You see the return echo’ed out. Yet the next line? Doesn’t happen.

and it’s not like the subroutine is doing anything complicated:

        :refresh_current_lyric_provider_metadatas [opt]
                iff "%CURRENT_LYRIC_PROVIDER%" == "LyricsGenius" .or. "%CURRENT_LYRIC_PROVIDER%" == "GENIUS" then
                        set CURRENT_LYRIC_PROVIDER=LyricsGenius
                        set CURRENT_LYRIC_PROVIDER_DISPLAY=LyricsGenius
                        set OTHER_LYRIC_PROVIDER=SyncedLyrics
                        set OTHER_LYRIC_PROVIDER_DISPLAY=SyncedLyrics
                else
                        set CURRENT_LYRIC_PROVIDER=SyncedLyrics
                        set CURRENT_LYRIC_PROVIDER_DISPLAY=SyncedLyrics
                        set OTHER_LYRIC_PROVIDER=LyricsGenius
                        set OTHER_LYRIC_PROVIDER_DISPLAY=LyricsGenius
                endiff
        return

To add insult to injury, the exact same scripts on the exact same files do NOT behave this way in a new TCC instance.

So it’s something in the environment that is getting corrupted. It’s not the script. It’s the environment exposing some kind of bug or weird behavior that is intentionally designed for a reason but which isn’t a bug but appears like one.

 

[Claire_CJS]

I don’t even know how to begin to diagnose this, not even with 38 years experience doing these things

To add insult to injury, the exact same scripts on the exact same files do NOT behave this way in a new TCC instance.

 

[Claire_CJS]

Annnnnnnnnnnnnnnnnd after some time, it stopped being reproduceable, even though it was before.

This may remain a mystery, but there’s defintiely something untoward about TCC 33.00.20 x64 and gosub. A "return" should not mean returning to the command prompt.

 

[rconn]

Not much I can do without a reproducible failcase.

 

[Alpengreis]

@Claire_CJS

:refresh_current_lyric_provider_metadatas
is ALWAYS done in such cases, right?

Sounds like a dumb question, but where could we start else??

Greetings

 

[Claire_CJS]

@Claire_CJS

:refresh_current_lyric_provider_metadatas
is ALWAYS done in such cases, right?

Sounds like a dumb question, but where could we start else??

Greetings

Right. It always finishes. I’m not sure how to even reproduce this. It’s a set of 2 bat files that both call each other from each other that total over 9,000 lines and rely on over 75 other scripts.

I just think.... SOMEthing is happening. I’m seeing it go into the subroutine, return, and then stop when there is NOTHING and NO REASON for it to do so.

It almost seems related to the way IFF handles things, because when i changed it to IF, it stopped being reproduceable.

 

[Claire_CJS]

Not much I can do without a reproducible failcase.

Right? It’s a big bummer. I guess this is more of a BOLO/be on the lookout. It may be due to different behavior with how IFF/ENDIFF enclosed gosubs work vs gosubs that are not enclosed in IFF/ENDIFF. But it’s definitely also related to SOMEthing in the environment for it to not behave the same in 2 adjacent tabs in the same windows terminal session. How maddening

 

[Alpengreis]

@Claire_CJS

Have you news about that?

Greetings

 

[Eric Pement]

@Claire_CJS

Have you news about that?

@Claire_CJS -

You said, "It’s a set of 2 bat files that both call each other from each other that total over 9,000 lines and rely on over 75 other scripts." Here's a few thoughts.

1) Is there any chance that you have identically-named :labels in both batch files? You could do a quick "grep --no-filename ... | sort | uniq --repeated" on the two files to check. (Unix versions of these commands. )

2) I know that failure does not occur predictably, but does it always fail at the same label name/position?

3) Since the two scripts "both call each other from each other" that looks like setting things up for confusion about the PID and parent PID. While I give you credit for writing mutually referential batch files, if there is some type of recursion going on, you might exhaust the number of nesting levels permitted, function space, alias space, free working memory, or general memory for batch files. TCC has MEMORY and %@WINMEMORY which might be invoked at strategic points in your script for diagnostic purposes.

4) You might try leaving breadcrumbs during the process, by creating disk files (named step01, step02, step03, ...) in a temporary directory while the scripts execute. When execution completes, the last task is to delete the files in the temporary directory. If the script aborts prematurely, you can look in the temporary directory to see at what step the process halted.

5) If you haven't done it already, rewrite the batch file to support a --debug or --diag or --verbose option switch, to enable additional diagnostic messages sent to the console and/or disk while the script executes.

Hope this helps.

 

[Claire_CJS]

1) @Claire_CJS -

You said, "It’s a set of 2 bat files that both call each other from each other that total over 9,000 lines and rely on over 75 other scripts." Here's a few thoughts.

1) Is there any chance that you have identically-named :labels in both batch files? You could do a quick "grep --no-filename ... | sort | uniq --repeated" on the two files to check. (Unix versions of these commands. )

2) I know that failure does not occur predictably, but does it always fail at the same label name/position?

3) Since the two scripts "both call each other from each other" that looks like setting things up for confusion about the PID and parent PID. While I give you credit for writing mutually referential batch files, if there is some type of recursion going on, you might exhaust the number of nesting levels permitted, function space, alias space, free working memory, or general memory for batch files. TCC has MEMORY and %@WINMEMORY which might be invoked at strategic points in your script for diagnostic purposes.

4) You might try leaving breadcrumbs during the process, by creating disk files (named step01, step02, step03, ...) in a temporary directory while the scripts execute. When execution completes, the last task is to delete the files in the temporary directory. If the script aborts prematurely, you can look in the temporary directory to see at what step the process halted.

5) If you haven't done it already, rewrite the batch file to support a --debug or --diag or --verbose option switch, to enable additional diagnostic messages sent to the console and/or disk while the script executes.

Hope this helps.

1) Ugh. You’re right. I need to first check for duplicate labels.

2) can’t tell/remember unfortunately

3) It doesn’t change the pid to my knowledge

4) logging is definiteyl an optoin

5) already have that :)