LiveCode Forums.

[Please help - this is killing my project.]

I've been making standalone apps for my project for quite a while now. All OK.

As of the end of last week, standalone apps I make are crashing on launch.

Problem report from the Mac system says:

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000008
Exception Codes: 0x0000000000000001, 0x0000000000000008

I have proved that I can make simple standalone apps and they work fine - my LiveCode set up seems OK.

My app works fine in development mode.

I don't believe I've made any significant changes to the app since the last time I was able to make a non-crashing version. All the relevant files and resources are present in the app contents.

The internet suggested that it might have something to do with the custom menubar for my app but I can make a test app with custom menus and all works fine. And previous versions with the same menubar have worked OK.

I have no idea where to begin to find the problem. I'm lost.

Some thoughts/questions
1. MacOS version?
2. LC version?
3. Do you have a current subscription if using LC create classic?
4. If you're using legacy version, has it been modified to run on whatever MacOS you're running?
5. Is this code related? create an empty project with no objects or code, make a standalone, does it crash?
6. Are your apps code-signed/hardened?

If an empty app crashes, then it's likely an LC issue - unless you are on latest LC Create / Classic, you are unlikely to get help from LC, but you can always try emailing support at livecode dot com.
If the empty app doesn't crash then you're probably doing something at startup LC doesn't like...

Thanks, Stam.

I've managed to work it out using a technique that should be more widely known - thanks to my colleague Ben Rubinstein for the suggestion.

Possible tip if you do get any kind of initialisation: put without a destination (which goes into the message box in the IDE) doesn’t normally produce a visible result in a standalone; but if you launch the app from the command line, i.e. in a terminal window, those messages appear in the terminal. So you can add ‘put’ commands in your setup code, openstack and open card handlers etc; and if nothing else get a sense of how far it gets before it crashes, and possibly which statement triggers the crash.

* to launch from the command line, you have to reference inside the package, i.e. if in the terminal you cd to the folder containing “Magpie.app”, then you launch it with Magpie.app/Contents/MacOS/Magpie

Using this idea I inserted a load of put statements to track where the crash was happening.

Turns out that my standalone app was crashing when it executed an answer command during initialisation. I guess the UI was not in a state to display the dialog (or something like that).

Turns out that my standalone app was crashing when it executed an answer command during initialisation. I guess the UI was not in a state to display the dialog (or something like that).

Glad you got is resolved, but I do not understand something. When you say "...executed an answer command during initialisation" can you say more about that? What is the difference between the "initialization" time and any other time in the starting up of your standalone?

Craig

Create a stack. Add a stack script:

on startUp
answer "Hello"
end startUp

The stack works fine in the dev environment.

However, if you make a standalone from this stack, it will crash on launch, as described above.

There must be something about the way that the answer dialog is implemented that means it's not ready when startup takes place.

Alex.

Wow. The app never opened at all. Removing that handler fixed it. Anyone have any insight?

If there is anyone listening in Scotland these days, I would report it.

Craig

Obviously only the mainstack (standalone stack) has been loaded at that point,
but not all of its substacks, like ASK and ANSWER dialog.

Should not crash however!

Klaus makes the point that everything in LC is just a stack. I forget that now and then, thinking (or rather not thinking at all) that the answer dialog is some different sort of object class. it is not.

Putting that handler in the card script also crashes the standalone.

But even if the standalone does not load those stacks, as Klaus says, why crash? In the IDE, the dialogs simply do not appear, which at least seems reasonable.

Craig

The IDE "catches" the "startup" message, so it will never affect your stacks!

Hmmm.

Any other messages that work in the IDE (wherever they are placed) but not as a standalone? I thought a complete engine was ported into the .app bundle, and everything worked exactly the same. I assume that was naive.

At least it does not "crash" in that the app does not automatically quit.

Craig

Just my take on this…

The dictionary states "The target of the startup message is the first card of the application's initial stack.", so I don't see the startup message as being appropriate to call an answer dialogue directly, although I totally agree that it should not crash, throwing an error message would be more user friendly, even using the try/catch command doesn't result in an error, just a crash.

If the "Answer" command is moved to the stack's first card and something like the following startUp command is used, it works as required…
Obviously "startUpMessage" is the name of the command set up in the card script to open the answer dialogue.

Using 1 tick also ensures the stack has enough time to load everything necessary to run before sending the message.

Also, I think a crash is always worth an error report to the LC QC team.

Paul

AlexM_Cogapp wrote: ↑

Tue Feb 10, 2026 10:51 am

Create a stack. Add a stack script:

on startUp
answer "Hello"
end startUp

The stack works fine in the dev environment.

However, if you make a standalone from this stack, it will crash on launch, as described above.

There must be something about the way that the answer dialog is implemented that means it's not ready when startup takes place.

It may be true with any component that has a GUI and resides outside the mainstack file.

That's just a guess, but the preOpen* messages are sent before rendering occurs, and startup before anything else at happens.

It may be that the GUI bindings with the OS routines needed for compositing haven't completed when startup uses something that needs to be rendered.

Submitting a bug report will at least draw attention to it, and hopefully it's as easy as just swapping a block of code. It's probably related to how how the standalone builder inserts backscripts into the queue, which may be an issue in something in those dialogs depends on those backscript routines.

To prevent such things, as well as differences between dev and runtime in general, some time ago I fell into the habit of putting my initialization code into a handler triggered my preOpenStack in the first card of the mainstack. Of course this only works in you're not opening and closing that stack during the session, safe enough here since I tend to reserve that stack only as an anchor for messages and resources, and use substacks or separate stackfiles for flexible UI handling.