#1438 Crash when calling displayline: Internal table overflow

[Hans Schülein]

When using Skim with sublime text / LaTeX it fires the following command, yielding an error message

$ /Applications/Skim.app/Contents/SharedSupport/displayline -r -g 40 /path/to/file.pdf /path/to/file.tex
236:254: syntax error: Internal table overflow. (-2707)

As far as I am aware this is new in 1.6.6. This makes using it with ST impossible. I think this only crashes on one of my two devices --- the one running Monterey.

[Christiaan Hofman]

It is just a script. So this looks to me more like a bug in sublime text. Note that the script has not changed, and neither has the support inside Skim.

[Christiaan Hofman]

Moreover, I see no problem running displayline from the (ordinary) command line.

[Christiaan Hofman]

And really, the AppleScript is absolutely not big, it is really small in fact. So that really cannot give a problem, un less you have a really bad AppleScript runner. Also, the line numbers (or whatever they mean) at the beginning of the message make no sense to me.

[Hans Schülein]

The problem for me occured too when running from the command line so it is not ST specific except if the command is malformed somehow. Reinstalling skim did not help. It was the only open PDF file.

It worked perfectly fine on my iMac on big sur on the exact same files. On my Monterey MacBook it crashes for every file I have tried so far.

I manually compiled Skim on the MacBook a few days ago to try the dark mode (it still worked then), but I switched to the release version before the bug happened. As far as I am aware the manual compilation worked every time and the release version crashes every time. Could this be related?

[Christiaan Hofman]

Do you perhaps have a really large amount of PDF documents open? There's really nothing else where the script even accesses multiple objects.

[Hans Schülein]

Reverse engineering a bit: simply running the AppleScript

tell application "Skim"
end tell

causes the internal table overflow. Console.app shows an automator related fault at that time:

index past end of termHandle (attempted 3916 > actual 3904)

I have 0 experience with AppleScript/Automator so I don't know what to do. Online searches also brought up nothing for me.

I am on the Monterey developer beta so I am afraid this might be related.

[Christiaan Hofman]

It must be the Monterey beta. We really don't do anything wrong (as you can see from the fact that it always worked before), and the script absolutely is not too large. Perhaps you can file a bug report with Apple on Monterey's AppleScript support, it can only be them.

[Christiaan Hofman]

I don't hope Apple has finally completely broken AppleScript support. I did hear stories that they are completely screwing up internally in the Automator department for a while now. I am not sure if they even have an active team anymore, having fired the lead developer.

[Christiaan Hofman]

I put a test version of Skim at https://skim-app.sourceforge.io/Skim.zip. Could either of you try this out and see whether it allows acting on by AppleScript, possible through displayline? Not too much change, but it is the only thing I can think of.

[Hans Schülein]

That URL 404s. I cannot download the file, but I will happily try it out :)

[Christiaan Hofman]

I see what happened, it added the final period to the URL. Here it is again:
https://skim-app.sourceforge.io/skim.zip

[Hans Schülein]

And this time you accidentally lower cased it ^^

It still does not work, same error. Interestingly before the first launch it crashed with

Job 1, '/Applications/Skim.app/Contents…' terminated by signal SIGKILL (Forced quit)

because I hadn't confirmed the "unknown developer" prompt yet. So the error has to happen after that point in the pipeline.

[Christiaan Hofman]

Yes, it did not go though Apple's security theater.

I replaced it with another more aggressive test version, indeed at
https://skim-app.sourceforge.io/Skim.zip

(I thought URLs were supposed to be case insensitive?)

[Hans Schülein]

URLs usually are case insensitive but sometimes you want to for example base64 encode sth in parameters and then you can use them as non-case sensitive. Apparently sourceforge decided on case sensitivity here. Maybe because they want to differentiate the same file in svn with and without capitalization.

Automator now yields

The application has a corrupted dictionary.

and a terminal run yields

Entity: line 286: parser error : Double hyphen within comment: <!--    <suite name="Text Suite" code="TEXT"
        d
            <!-- this "type" element and the ones that follow, while they
              ^
Entity: line 329: parser error : Opening and ending tag mismatch: dictionary line 4 and class
        </class>
                ^
Entity: line 331: parser error : Extra content at the end of the document
        <class name="character" code="cha "
        ^
236:254: syntax error: The application has a corrupted dictionary. (-2705)

(the last error was -2707)

[Christiaan Hofman]

Sorry. I made another try...

[Hans Schülein]

Good news! Automator now runs

    tell application "Skim"
        activate
    end tell

without the table-error

running the full command on the commandline however now yields a new and exciting error:

603:607: syntax error: Expected end of line but found class name. (-2741)

[Christiaan Hofman]

That can make sense, I removed just a bit too much for displayline to run.

Anyway, I now have an idea where Monterey's bug lies. Apple apparently does not allow extensive scriptability anymore! It is really annoying they did this, and I hope they will fix this (soon).

Was this already a problem in 12.0, or is this new in the 12.1 beta?

[Hans Schülein]

I think it was still working fine a week ago, so according to that reasoning it must have been the latest beta. But I don't have a device on that beta anymore so I cannot confirm it.

Is there a way to fix this that does not require action on Apple's side, or will applescript capability just be broken in 12.1+ forever?

I wil happily test another version for you.

[Christiaan Hofman]

Just to be clear, it was working for you earlier on 12.0.1? And now it fails for you on 12.1 beta 3? And that is where you tried the test version that allowed automation?

As for the fix, I really think it should be fixed by Apple. But they often are very slow to act, or even acknowledge this kind of bugs. On the other hand, if it worked on 12.0, I don't see why they could not easily reverse the bug they introduced in 12.1, perhaps even before their release.

The problem seems to be that they reduced the size of the memory they use to store the scripting definition of the apps, or somewhere else something wastes a lot of extra memory. We could fix this by scrapping part of the scripting support. But I would have no idea how much we need to scrap.

[Christiaan Hofman]

And I replaced the test version with one that tries to do this more than before. Could you please test it?

[Hans Schülein]

i think it was working fine in the last beta but not in this one.

the new version is back to a table overflow

[Christiaan Hofman]

And the last beta was a 12.1 beta, or a 12.0.x beta?

I have yet again replaced the test version with an even smaller sdef. Beginning to touch the more relevant stuff...

[Hans Schülein]

I am not sure what version I was on before, sorry. The new version still yields the table overflow.

Somehow I am not getting any email notifications for this thread anymore. Does SF stop doing that after a certain depth?

I am having some other issues with the current developer beta of macOS, maybe the next one magically fixes everything

[Christiaan Hofman]

Have you ever tried downloading the previous release to see if that works on the 12.1 beta?

Not too much chance, as the changes are very minor and really should not stop scripting.