LiveCode Forums.

Hello LC friends and specialists,

I have the following problem and I hope someone can help me.
I have built an extensive application (Windows 11 Home and LC 9.6.11) and when run a certain card after a while the Application including LiveCode just quits and closes everything.

How can I Find out where this happens within the application?
Is there a Log saved so I can see why and where in the application the cause could be?

Hope any of you have good suggestions on how to troubleshoot this.

Regards,

Paul

Hi.

It quits while just idle and open? Or while some process is running?

Craig

Hi Craig,

It crashes while running.
So I need to find out what is happening.
I have a field that shows memory usage but this shows no issue with memory usage buildup.

Regards,

Paul

I usually put this in some central stack script of library stack in my projects:
Then I put, in every handler that I want to log, the line: It can go multiple times in each handler if needed, after every crucial step, so I can see exactly where things go wrong (i.e. the last log entry before the crash).

Finally, I switch on the logging by doing in the message box (or in a checkbox button or so).

To switch off the logging, do The nice thing is that by keeping all this debugging code in the finished product, and having a checkbox for the end user to tick if so instructed by me, I can have them send me an error log if they experience crashing problems.

Thanks for the example code SWEdeAndy
Seems like a good way to trace problems.
I will give it a try

Regards,

Paul

No problem. I think you'll get a long way with this. But just in case of future readers who may be less experienced, I will summarise/elaborate:

I use the method above for debugging when:
1) the IDE crashes on me,
2) a standalone crashes or malfunctions when I'm testing it,
3) a standalone crashes or malfunctions for an end user.

The file "eventlog.txt" (or whatever you want to name it) will automatically be created if it doesn't exist. Further error logging will never overwrite anything in it, just append to the end of the file. This means you can also delete it at any time to start over with a fresh log.

In my example script, the log file will be created wherever the defaultFolder points to - normally the folder where the stack file resides.
You may want to provide another file path, such as specialFolderPath("documents"), especially for end user standalones, to avoid permission issues and so that the user can easily locate and send the file to you, if relevant.

The execution speed of your code will naturally be impacted by extensive use of the log command, depending of course on how it's implemented etc. So it would be good practice to set the logmessage to empty in openStack/Card or similar, and only turn it on "manually" when needed.

In one project I even had early in the splash/launcher stack a line like just in case something went wrong during initialisation, before the user could even reach the place where they could switch on logging.

When the logmessage is set to empty, LiveCode ignores all log commands, ensuring that your code executes at full speed. Thus you never need to go through your code and "comment out" the log commands - just leave them dormant there for when that improbable but inevitable bug pops up from the quantum foam...

SWEdeAndy et al.

Anyone have a problem with this part of the discussion being reposted in its own thread? It would make it easy to find later on if, say, the title was something like "Logging to identify problems and crashes"

Wowsers Andreas, thank you!

I was only vaguely aware of the log command and had never really used it - thank you for providing an actual real life example, saved me a lot of headache figuring out how to actually use this!
I was also completely unaware of the ; keyword... that's hugely helpful!!

If you want to explore an option that requires no changes to your code, and you don't mind LARGE log files:
https://fourthworld.net/lc/4wLogCrash.livecode

This one works by inserting a front script when you click the "Active" checkbox,which traps every system message and custom handler call. Yes, the log gets big fast, but at least it's thorough.

The underlying mechanism is a seldom-needed global property named the messageMessages. Off by default, when true the engine will send a message notifying about every call being made. When there's a matching handler in the message path the message will be messageHandled, and when no matching handler is queued the message sent will be messageNotHandled (never used that myself, but might be useful is some rare cases involving the dispatch command).

To use, just open the stack and click "Active", then run whatever you do until you crash. You'll find a log file waiting for you on your desktop.

dunbarx wrote: ↑

Tue Jan 09, 2024 10:49 pm

SWEdeAndy et al.

Anyone have a problem with this part of the discussion being reposted in its own thread? It would make it easy to find later on if, say, the title was something like "Logging to identify problems and crashes"

Sure, that could be useful. If it's not feasible to maybe edit the title of this one a little to reflect the logging theme? But that would be up to the OP then.

stam wrote: ↑

Wed Jan 10, 2024 1:22 am

Wowsers Andreas, thank you!

I was only vaguely aware of the log command and had never really used it - thank you for providing an actual real life example, saved me a lot of headache figuring out how to actually use this!

Yeah, it's been around for quite a while, and I think there was if not an LC lesson then at least a blog post about it at some point, but I didn't get around to explore it until one or two years ago. It can be really useful.

I was also completely unaware of the ; keyword... that's hugely helpful!!

Heh, I don't even know why I threw that one in in that particular code example. I practically never use semicolon in actual code, as I feel it harms the readability of the code structure. Here I think I just wanted to make it a one-liner, as the post got a bit long anyway. But as it turns out, that too was knowledge sharing!