text copied form LC generated PDF, WTF?

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Diagnosing a crasher (was Re: Quality, reputation, and improving both)

Paul Hibbert via use-livecode
Richard.
 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.
Craig

-----Original Message-----
From: Richard Gaskin via use-livecode <[hidden email]>
To: use-livecode <[hidden email]>
Cc: Richard Gaskin <[hidden email]>
Sent: Thu, Feb 20, 2020 9:08 pm
Subject: Diagnosing a crasher (was Re: Quality, reputation, and improving both)

dunbarx wrote:

 > 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
    intensely.
    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
 > wrote.

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.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Diagnosing a crasher (was Re: Quality, reputation, and improving both)

Paul Hibbert via use-livecode
dunbarx wrote:> Richard.
 >  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.

That's kind of you to say.  And I am working on some things for the
community, so perhaps best to keep my focus on those, at least for now.

If you discover a recipe, or even anything close to a pattern, maybe the
first thing I'd do is add some logging.  Logs are great for crashers, as
the last line that successfully executed will usually provide some good
clues.

Here's a simple logger I made a while back, not fancy but it gets the
job done:
http://fourthworld.net/lc/4wLogger.livecode.zip

If you happen to run it when you have a crash, maybe email me the last
hundred lines or so (but not the whole thing, please; as you'll see, it
makes a _very_ verbose log).

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

<

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Diagnosing a crasher (was Re: Quality, reputation, and improving both)

Paul Hibbert via use-livecode
In reply to this post by Paul Hibbert via use-livecode
I'm having the same problem. I had to build with the latest 9.6dp release
because it fixed some Android issues and I had a deadline. It's in the Play
Store now and it's had several crashes and ANRS. There's no info on the
cause and we couldn't repeat it. We're about to submit the iOS app now and
my testers have had several intermittent crashes we can't repeat, even
though I built that one with 9.5.1 stable. I submitted crash logs but the
team could only repeat the problem once and there's no real recipe. How
would you trace something like that?

It feels like a memory leak to me but that could happen anywhere in the
app. Wherever it is, it goes back a ways.
--
Jacqueline Landman Gay | [hidden email]
HyperActive Software | http://www.hyperactivesw.com
On February 20, 2020 10:40:59 PM dunbarx--- via use-livecode
<[hidden email]> wrote:

> So I am fascinated; how would you even start? It isn't one handler that
> causes the problem.



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Diagnosing a crasher (was Re: Quality, reputation, and improving both)

Paul Hibbert via use-livecode
J. Landman Gay jacque wrote:
 > We're about to submit the iOS app now and my testers have had several
 > intermittent crashes we can't repeat, even though I built that one
 > with 9.5.1 stable. I submitted crash logs but the team could only
 > repeat the problem once and there's no real recipe. How
 > would you trace something like that?

Only iOS or in development too?

I'd consider running a logger, but if it's not merely intermittent but
also rare, the challenge is that a logger will slow things down a little
bit while you're working, writing giant log files that most of the time
aren't needed.


Hmm...

 > It feels like a memory leak to me but that could happen anywhere in
 > the app. Wherever it is, it goes back a ways.

How far back?  In which version did you first start seeing this?

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Diagnosing a crasher (was Re: Quality, reputation, and improving both)

Paul Hibbert via use-livecode

Chiming in again since it dovetails with today's work:

Crashing bugs (and others) sometimes require a missing
factor/context/detail in the original real-world project that is tricky
to reproduce in independent test stacks. You have to compensate for that.

I filed this crasher today, but had to use a slightly more "extreme"
example compared to the original real-project-crasher to get 100%
reliable open-click-crash independent test stack:

(Save work before running)

https://quality.livecode.com/show_bug.cgi?id=22586

Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

RE: Diagnosing a crasher (was Re: Quality, reputation, and improving both)

Paul Hibbert via use-livecode
I have an IDE bug that I have to get a recipe for. It might not be possible
to whittle this one down and I might have to send Panos the full stack with
data files off line.

1) After the openCard message is passed to the engine if the script editor
is open the engine loops for 5-10 seconds before the IDE is once again
responsive. On Windows the IDE and stack window(s) get that red at the top
right. If you click anywhere you get the "Not Responding" in the title bar.
Close the script editor and speed is back to normal. Open it back up and
it's slow again but not instantly. I doesn't happen on all cards though. I
traced and traced it but an F11 after the last opencard handler and the IDE
just loops for a while(if the script editor is open) and the fans get
louder. It took a while before I realized that just closing the script
editor would get things going again and I could test changes to the card.

2) The above and this might be related to the slow stack saving on Windows.
Unzipping a 2mb zip file with fair amount(400 so) smallish files(4mb
unzipped) using revzip also locks up the IDE and gets the "Not Responding"
thingy for 20 or so seconds. On both mobile platforms it's sub second for
the same code using the same zip file.

By the way.. Using 9.0.5,9.5.1,9.6dp2 I have not seen a CTD is a while.

3) Another thing I've seen is IDE locking up when exiting. Open a small
stack(GUI and code) and maybe make a change or two then close the IDE after
saving the changes. The IDE closes a stack window / tool pallet or two then
opens up a script editor window named "new script editor 1". Then the IDE
goes into a tight loop and I have to stop the process. This happens once
every 30 to 50 times I use the IDE.

I can get a recipe for #1 and #2 but 3 is random and happens with any stack.

Annoying yes. The the amount of productivity I get out is still far beyond
any other language I know and still outweighs the time it take to do the
occasional bug report.

Ralph DiMola
IT Director
Evergreen Information Services
[hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Diagnosing a crasher (was Re: Quality, reputation, and improving both)

Paul Hibbert via use-livecode
In reply to this post by Paul Hibbert via use-livecode
Curry.
We are all fortunate in that you found the culprit in a single command in a line of code.
It crashes LC 9.5.1 in Mac OS. If I change the second parameter (tDel) to a single char, all is well,
The issues I am having with my project occur in random places in different handlers at random times.
This is not stopping me. Saving often allows me to forge ahead, with good results. Been doing this for at least two years.
Craig

-----Original Message-----
From: Curry Kenworthy via use-livecode <[hidden email]>
To: use-livecode <[hidden email]>
Cc: Curry Kenworthy <[hidden email]>
Sent: Fri, Feb 21, 2020 1:55 pm
Subject: Re: Diagnosing a crasher (was Re: Quality, reputation, and improving both)


Chiming in again since it dovetails with today's work:

Crashing bugs (and others) sometimes require a missing
factor/context/detail in the original real-world project that is tricky
to reproduce in independent test stacks. You have to compensate for that.

I filed this crasher today, but had to use a slightly more "extreme"
example compared to the original real-project-crasher to get 100%
reliable open-click-crash independent test stack:

(Save work before running)

https://quality.livecode.com/show_bug.cgi?id=22586

Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Diagnosing a crasher (was Re: Quality, reputation, and improving both)

Paul Hibbert via use-livecode
In reply to this post by Paul Hibbert via use-livecode
On 2/21/20 2:44 AM, Richard Gaskin via use-livecode wrote:
> J. Landman Gay jacque wrote:
>  > We're about to submit the iOS app now and my testers have had several
>  > intermittent crashes we can't repeat, even though I built that one
>  > with 9.5.1 stable. I submitted crash logs but the team could only
>  > repeat the problem once and there's no real recipe. How
>  > would you trace something like that?
>
> Only iOS or in development too?

Never in the IDE, frequently in the iOS standalone, sometimes in the Android app. It seems to
depend on how long you use the app. I have never had a crash because I do unit testing and then
quit. The testers pound on it hard and they get most of the crashes because they're at it for
hours. On the other hand, my client took the Android app to a trade show and demo'ed it for 8
hours a day and never crashed. So maybe it's device-dependent? Who knows. My primary tester has
a budget Moto phone, my client has a Pixel 2. That's why I'm thinking it may be memory-related.

>
> I'd consider running a logger, but if it's not merely intermittent but also rare, the challenge
> is that a logger will slow things down a little bit while you're working, writing giant log
> files that most of the time aren't needed.

Both intermittent, not reproducible on demand, and never consistent. A logger would probably be
difficult to deal with on a mobile device, but more importantly, it could only tell us what
actions the user took before the crash. Since we've tried repeating the same actions many times
without any problem, there's really nothing to point a finger at.

>
>  > It feels like a memory leak to me but that could happen anywhere in
>  > the app. Wherever it is, it goes back a ways.
>
> How far back?  In which version did you first start seeing this?

The earliest build I did was in 9.0-something but the testers never got the mobile app until I
built with 9.5.1 so I'm not sure. I should have said "goes back at least to 9.5.1."

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Diagnosing a crasher (was Re: Quality, reputation, and improving both)

Paul Hibbert via use-livecode
All.
It did just occur to me that ALL my crashes occur when the SE is open. Never just playing with the stack. I am trying to remember now whether I am modifying code or not when the crash occurs. The problem, (actually the beauty, of course) of LiveCode is that one can jump in a and out of the SE rapidly as one develops.
 I will have to pay more attention.
Aha.
Craig


-----Original Message-----
From: J. Landman Gay via use-livecode <[hidden email]>
To: How to use LiveCode <[hidden email]>
Cc: J. Landman Gay <[hidden email]>
Sent: Fri, Feb 21, 2020 3:24 pm
Subject: Re: Diagnosing a crasher (was Re: Quality, reputation, and improving both)

On 2/21/20 2:44 AM, Richard Gaskin via use-livecode wrote:
> J. Landman Gay jacque wrote:
>  > We're about to submit the iOS app now and my testers have had several
>  > intermittent crashes we can't repeat, even though I built that one
>  > with 9.5.1 stable. I submitted crash logs but the team could only
>  > repeat the problem once and there's no real recipe. How
>  > would you trace something like that?
>
> Only iOS or in development too?

Never in the IDE, frequently in the iOS standalone, sometimes in the Android app. It seems to
depend on how long you use the app. I have never had a crash because I do unit testing and then
quit. The testers pound on it hard and they get most of the crashes because they're at it for
hours. On the other hand, my client took the Android app to a trade show and demo'ed it for 8
hours a day and never crashed. So maybe it's device-dependent? Who knows. My primary tester has
a budget Moto phone, my client has a Pixel 2. That's why I'm thinking it may be memory-related.

>
> I'd consider running a logger, but if it's not merely intermittent but also rare, the challenge
> is that a logger will slow things down a little bit while you're working, writing giant log
> files that most of the time aren't needed.

Both intermittent, not reproducible on demand, and never consistent. A logger would probably be
difficult to deal with on a mobile device, but more importantly, it could only tell us what
actions the user took before the crash. Since we've tried repeating the same actions many times
without any problem, there's really nothing to point a finger at.

>
>  > It feels like a memory leak to me but that could happen anywhere in
>  > the app. Wherever it is, it goes back a ways.
>
> How far back?  In which version did you first start seeing this?

The earliest build I did was in 9.0-something but the testers never got the mobile app until I
built with 9.5.1 so I'm not sure. I should have said "goes back at least to 9.5.1."

--
Jacqueline Landman Gay        |    [hidden email]
HyperActive Software          |    http://www.hyperactivesw.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Diagnosing a crasher (was Re: Quality, reputation, and improving both)

Paul Hibbert via use-livecode
dunbarx wrote:
 > All.
 > It did just occur to me that ALL my crashes occur when the SE is open.
 > Never just playing with the stack. I am trying to remember now whether
 > I am modifying code or not when the crash occurs. The problem,
 > (actually the beauty, of course) of LiveCode is that one can jump in
 > a and out of the SE rapidly as one develops.
 >  I will have to pay more attention.
 > Aha.
 > Craig

Interesting.

May or may not be related, but the issue Mark Wieder described last
night is also specific to the script editor.  Rather than a crasher, his
issue was mysterious in a different way,:scripts being saved into
objects other than the ones they came from.  That's something I've never
seen in any script editor in our community before, and having written a
couple I can't even imagine how that happens.
http://lists.runrev.com/pipermail/use-livecode/2020-February/258623.html

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Diagnosing a crasher (was Re: Quality, reputation, and improving both)

Paul Hibbert via use-livecode
Not to cast aspersions on anyone's work, but there is an alternate script editor that misbehaved in a similar way when switching between the native editor and the alternate one. That has been ironed out some time ago, but for the sake of historical accuracy... well... there you go.

Bob S


> On Feb 21, 2020, at 13:53 , Richard Gaskin via use-livecode <[hidden email]> wrote:
>
> dunbarx wrote:
> > All.
> > It did just occur to me that ALL my crashes occur when the SE is open.
> > Never just playing with the stack. I am trying to remember now whether
> > I am modifying code or not when the crash occurs. The problem,
> > (actually the beauty, of course) of LiveCode is that one can jump in
> > a and out of the SE rapidly as one develops.
> >  I will have to pay more attention.
> > Aha.
> > Craig
>
> Interesting.
>
> May or may not be related, but the issue Mark Wieder described last night is also specific to the script editor.  Rather than a crasher, his issue was mysterious in a different way,:scripts being saved into objects other than the ones they came from.  That's something I've never seen in any script editor in our community before, and having written a couple I can't even imagine how that happens.
> http://lists.runrev.com/pipermail/use-livecode/2020-February/258623.html
>
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12