Diagnosing a crasher (was Re: Quality, reputation, and improving both)
dunbarx at aol.com
dunbarx at aol.com
Thu Feb 20 23:38:53 EST 2020
I will keep a eye out to see if something I do or some particular section of code which causes a crash.
I have no issue with sending you my stack; it is only for internal use. But there are many handlers in many controls on many cards, all in a mainStack and a handful of substacks. I do feel, though, that the problem occurs when handlers in the mainStack are being worked on.
So I am fascinated; how would you even start? It isn't one handler that causes the problem. You would not even know how to use the thing, and therefore could not really put it through its paces.
I feel this would be a waste of your time, and though the offer is priceless, I have always felt that, in particular, your time is far more priceless.
From: Richard Gaskin via use-livecode <use-livecode at lists.runrev.com>
To: use-livecode <use-livecode at lists.runrev.com>
Cc: Richard Gaskin <ambassador at fourthworld.com>
Sent: Thu, Feb 20, 2020 9:08 pm
Subject: Diagnosing a crasher (was Re: Quality, reputation, and improving both)
> Richard wrote:
>> Crashers are of course serious, but the good news is that you're only
>> seeing it in one project. Feel free to email me directly if you're
>> in a position to allow me to review the errant code, and I'll see
>> what we can do to both find a workaround to keep your progress moving
>> along well, and submit a report for the underlying cause once we find
>> it. This happens all over the place, and seems to occur only after
>> the stack has been fiddled with for a while.
> This happens all over the place, and seems to occur only after the
> stack has been fiddled with for a while.
Apparently I was mistaken. When I read:
"I must add that I am working mainly on a single project when this
happens, and am conditioned to save often. The other projects I
have currently do not exhibit this at all, though that may be
simply due to the fact that I am involved in them much less
I suppose it is less worrisome that this is a problem in only a
single project, than if it happened here and there, everywhere.
...I got the impression that it was a problem in only one single
project, less worrisome than if it happened in others.
Do you see a pattern to the crashes that might lead to a recipe?
> I cannot imagine that anything can be gleaned from the code base,
> which is 9000 lines of straight LC, with only a smattering of
> printing, printing to PDF, creating text files and reading and writing
> to them.
Software is code. I already have the engine code.
I'm of the opinion that crashers are something that ideally should never
happen in any scripting language. So even if there's something we can
change in your code to eliminate the crash, I'd still submit a bug
report to see if a more graceful degradation is possible.
You're not obliged to accept the help.
> In fact, none of those "outside LC" gadgets have ever caused a crash.
That may be useful diagnostic info. What is an "'outside LC' gadget"?
> The bugaboo is inside somewhere; I do not believe it is something I
If you wrote nothing no crash would occur. :)
I'm not interested in seeking blame, only in seeking solutions. And as
I've said above, if there needs to a be any sort blaming we can always
blame crashes on the engine. So even if we find a workaround in which
we change your script to stop the crash, that it resulted in a crash and
not an error dialog implies an opportunity to further refine LC's
exception handling. And along the way you'd see the end to a
long-standing crasher that's been interrupting your workflow.
> Can I say "bugaboo" which is not a bug, but rather something that just
> bugs me?
Sure, feel free to say anything you like. But to me, any crash in any
scripting language is a serious issue that merits further diagnosis.
If I can help diagnose this one I'd be happy to lend a hand.
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
Ambassador at FourthWorld.com http://www.FourthWorld.com
use-livecode mailing list
use-livecode at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the use-livecode