Finding bugs
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- Posts: 84
- Joined: Mon Apr 06, 2020 1:19 pm
- Contact:
Finding bugs
Hi:
I've rewritten a standalone app of mine recently (upgrades) and it works like a charm, fast, clean almost beautiful in a way. However, it has started to crash from time to time and it is a very hard bug to find (I guess it could be more than one; I don't know). I wondered if this might be a generally useful enquiry:
Do those who are rather brilliant at bug finding have any techniques beyond the obvious for identifying such problems? (my crashes do not always happen at the same place in my code and most of the time it works flawlessly so finding the cause is very tricky. There is no obvious set of circumstances that causes it. It does not happen after a regular interval. In fact, as far as I can see, there is nothing evidently regular about it.
Also, I'd imagine with enough experience you might have built a "usual suspects" ordered list of the most common causes - somewhere to start one's search.
What's causing mine? No idea. I assume it is some strange set of circumstances that occasionally conspire to cause the problem - it does not appear to be anything as obvious as an errant line of code. I've spent 5+ hours already trying to find this bug. I'm making the same rate of progress as a baby trying to get food in its mouth as opposed to all over its face.
I've rewritten a standalone app of mine recently (upgrades) and it works like a charm, fast, clean almost beautiful in a way. However, it has started to crash from time to time and it is a very hard bug to find (I guess it could be more than one; I don't know). I wondered if this might be a generally useful enquiry:
Do those who are rather brilliant at bug finding have any techniques beyond the obvious for identifying such problems? (my crashes do not always happen at the same place in my code and most of the time it works flawlessly so finding the cause is very tricky. There is no obvious set of circumstances that causes it. It does not happen after a regular interval. In fact, as far as I can see, there is nothing evidently regular about it.
Also, I'd imagine with enough experience you might have built a "usual suspects" ordered list of the most common causes - somewhere to start one's search.
What's causing mine? No idea. I assume it is some strange set of circumstances that occasionally conspire to cause the problem - it does not appear to be anything as obvious as an errant line of code. I've spent 5+ hours already trying to find this bug. I'm making the same rate of progress as a baby trying to get food in its mouth as opposed to all over its face.
-
- VIP Livecode Opensource Backer
- Posts: 10044
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
Re: Finding bugs
There is one way to solve all problems: identify the differences between the working and non-working states.bbalmerTotalFluency wrote: ↑Sun Jun 30, 2024 4:15 amDo those who are rather brilliant at bug finding have any techniques beyond the obvious for identifying such problems?
We can explore logs and other diagnostics, but the solution space is vast and we don't yet have the means to narrow what we'd be looking for, so let's start at the beginning:
Can you list the changes to all parts of the system (your scripts, your data, LC engine, OS version, hardware config, etc) that changed between now and the last time the system did not show this error?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- Posts: 84
- Joined: Mon Apr 06, 2020 1:19 pm
- Contact:
Re: Finding bugs
slack programming practices especially focussed on insufficient testing - means that I cannot answer that eminently reasonable question.
I shall sit in the corner for 30 minutes and take the time to reflect on bad things I have done.
I shall sit in the corner for 30 minutes and take the time to reflect on bad things I have done.
Re: Finding bugs
I have sometimes encountered some frustrations with a standalone that crashes while the IDE version works perfectly.
I don't know if this is your case. If it is, I believe that there is a third party stack or an external one which allows you to debug a standalone in the same way as a stack running with the IDE. I don't remember the name of this tool but I think that some members here who are more experienced than me know this tool.
I don't know if this is your case. If it is, I believe that there is a third party stack or an external one which allows you to debug a standalone in the same way as a stack running with the IDE. I don't remember the name of this tool but I think that some members here who are more experienced than me know this tool.
Re: Finding bugs
MY question is: " "Did the earlier version ever crash?"
If not, and we can set aside LC and OS version differences (we likely can) then you have to compare the scripts of each stack section by section, where a "section" is where each "functionality" lives. You can run each stack version side by side on the same screen, setting breakpoints where you feel each "section" lives, and track the state of each stack as you progress.
It is unlikely that there is a hidden corruption in your new version, since sporadic crashes here and there usually do not That work that way. But the main thing is to see if crashes occur when the same routines are run. That is hard to do with intermittent problems; one almost wishes the crashes occurred all the time. This can be tedious, but should give a eureka moment.
Good luck...
Craig
If not, and we can set aside LC and OS version differences (we likely can) then you have to compare the scripts of each stack section by section, where a "section" is where each "functionality" lives. You can run each stack version side by side on the same screen, setting breakpoints where you feel each "section" lives, and track the state of each stack as you progress.
It is unlikely that there is a hidden corruption in your new version, since sporadic crashes here and there usually do not That work that way. But the main thing is to see if crashes occur when the same routines are run. That is hard to do with intermittent problems; one almost wishes the crashes occurred all the time. This can be tedious, but should give a eureka moment.
Good luck...
Craig
-
- VIP Livecode Opensource Backer
- Posts: 10044
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
Re: Finding bugs
No blame. Intermittent issues are murky and difficult to diagnose.bbalmerTotalFluency wrote: ↑Mon Jul 01, 2024 10:08 amslack programming practices especially focussed on insufficient testing - means that I cannot answer that eminently reasonable question.
I shall sit in the corner for 30 minutes and take the time to reflect on bad things I have done.
Can you think of anything at all that has changed?
Is there a particular area of activity where the bug shows itself more than others?
I have logging and other diagnostic tools, but too much logging is as useless as too little.
Any observations that can narrow down the search for the root cause will be helpful.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- Livecode Opensource Backer
- Posts: 10094
- Joined: Fri Feb 19, 2010 10:17 am
Re: Finding bugs
All I can offer is what I do: clog up endless old hard drives I picked up for about $5 each with backups of my Devawriter code base . . . and I cannot work out how many times I have had to back track through 15 - 20 back ups: but, frustrating as it it it has saved me from ending up with 'jam all over my face.'
Re: Finding bugs
The tool is built into LC and is called Remote Debugging. It may be a feature only available in one of the higher tiered licenses though. It allows you to debug standalones the same way you do in the IDE, and opens the script editor on your computer so you can step through and into lines of code.Zax wrote: ↑Mon Jul 01, 2024 11:25 amI have sometimes encountered some frustrations with a standalone that crashes while the IDE version works perfectly.
I don't know if this is your case. If it is, I believe that there is a third party stack or an external one which allows you to debug a standalone in the same way as a stack running with the IDE. I don't remember the name of this tool but I think that some members here who are more experienced than me know this tool.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
-
- Posts: 84
- Joined: Mon Apr 06, 2020 1:19 pm
- Contact:
Re: Finding bugs
Wow! That's an awesome bit of knowledge. Thank you. Will look into that today.
I do hope when asking questions, in the spirit of forums, answers will be of value to others. I think this one will be for sure.
I do hope when asking questions, in the spirit of forums, answers will be of value to others. I think this one will be for sure.
-
- Posts: 919
- Joined: Wed Nov 04, 2009 11:41 am
Re: Finding bugs
Hi,
I'm late to this thread but will make the following observations. Errors and crashes happen for a reason. So these seemingly random crashes are occurring because some not often called code is running and failing.
When I am in a similar position I add a field named debug to the UI and add lines to the field that describe the applications progress e.g "Calling handler MyHandler" & cr and "Handler : MyHandler runs" etc etc. If I can't use a field for some reason the text may be written out to a text file. Another idea is to add "try" "end try" blocks to your handlers.
If your code uses Datagrids then recheck the code that interfaces with the datagrid. Datagrids are complex and quite sensitive and errors may go unreported as the error message gets lost deep within Livecode. In the past I have deleted one or more datagrids and then added them back. In a few situations I have removed them altogether and used a table field or Bernd's excellent modTableField.
Lastly, its a great idea to keep regular backups of your code. I use the attached plugin which automates the process, its a little ugly but does the job.
Good luck
S
I'm late to this thread but will make the following observations. Errors and crashes happen for a reason. So these seemingly random crashes are occurring because some not often called code is running and failing.
When I am in a similar position I add a field named debug to the UI and add lines to the field that describe the applications progress e.g "Calling handler MyHandler" & cr and "Handler : MyHandler runs" etc etc. If I can't use a field for some reason the text may be written out to a text file. Another idea is to add "try" "end try" blocks to your handlers.
If your code uses Datagrids then recheck the code that interfaces with the datagrid. Datagrids are complex and quite sensitive and errors may go unreported as the error message gets lost deep within Livecode. In the past I have deleted one or more datagrids and then added them back. In a few situations I have removed them altogether and used a table field or Bernd's excellent modTableField.
Lastly, its a great idea to keep regular backups of your code. I use the attached plugin which automates the process, its a little ugly but does the job.
Good luck
S
best wishes
Skids
Skids