[Bug]: "NSGetSizeAndAlignment(): unsupported type encoding spec 'p' at 'OpaqueAEDataStorageType}}16' in '{OpaqueAEDataStorageType}}16'"

[n8henrie]

Before submitting your bug report, please confirm you have completed the following steps

• Searched the issue is not already listed in the Issue List (I've searched it)
• Searched in the Quicksilver Users' Group for questions relating to tech support.
• Downloaded the latest version of Quicksilver for your system and confirmed the issue still persists.

Bug description

Turning on breakpoints for ObjC exceptions, upon running QS I'm immediately greeted by the below exception at

Quicksilver/Quicksilver/PlugIns-Main/QSCorePlugIn/Code/QSAppleScriptActions.m

Line 448 in 2812fe5

OSAScript *script = [[OSAScript alloc] initWithScriptDataDescriptor:aed

Thread 1: "NSGetSizeAndAlignment(): unsupported type encoding spec 'p' at 'OpaqueAEDataStorageType}}16' in '{OpaqueAEDataStorageType}}16'"

It is trying to load a JXA script (.scpt) file when this happens. It seems that removing these files from my Actions directory allows it to get past this point.

Steps to reproduce

1. Enable objc breakpoints for exceptions
2. Run QS

Expected behavior

No exception

MacOS Version

15.2

Quicksilver Version

2.4.3

Relevant Plugins

No response

Crash Logs or Spindump

No response

Screenshots

No response

Additional info

$ sw_vers
ProductName:            macOS
ProductVersion:         15.2
BuildVersion:           24C101

Not finding much helpful info online:

• NSGetSizeAndAlignment(): unsupported type encoding spec facebook/FBRetainCycleDetector#3: just don't use breakpoints for exceptions?
• NSInvalidArgumentException: NSGetSizeAndAlignment(): unsupported type encoding spec 'G' at 'GPoint}"size"{CGSize}}' in '{CGPoint}"size"{CGSize}}' JXA-Cookbook/JXA-Cookbook#53: maybe a macOS problem?

[n8henrie]

Also getting a crash when trying to run AppleScripts, unclear if related:

EDIT: User error, removing this comment. I had a few applescripts with the executable bit set, so QS then exposed the Run [...] action which tries to execute them directly. Removing the executable bit prevents QS from trying to run them directly, and they still run properly with the Run applescript action.

The issue above is still valid though.

[pjrobertson]

Can you provide the applescript for testing?

[n8henrie]

Oh, interesting. It's because my default action is Run [...] instead of Run. The former has subscript to specify that it's for shell scripts, and the latter that it's for AppleScript.

If I choose the one for shell scripts, it crashes. If I choose the one for AppleScript, it runs without error.

So user error, but could probably be improved.

[n8henrie]

See edit above. Needed to remove the executable bit from these scripts so QS doesn't expose the Run [...] action.

[pjrobertson]

Fixed in version 2.6.1 of the Terminal plugin. Will display a notification if the command failed