LC 8 Random crash with QT set the filename of player on OS X

Dar Scott dsc at swcp.com
Fri Jun 3 17:46:09 CEST 2016


I'm glad I was able to (somehow) help you tinker with this.

My style is to use send in many situations and I often create send loops or I build services with callbacks.  To my brain this keeps things simple.  And it is consistent with the event model that LiveCode uses.  

Dar

> On Jun 3, 2016, at 6:57 AM, Tiemo Hollmann TB <toolbook at kestner.de> wrote:
> 
> Hi Dar,
> 
> thank you for your notions.
> I think it wasn't a real recursion, because of the user interaction in
> between, but you pointed me into the right direction.
> I now have changed one call of a command with a *send* in 1 milliseconds
> instead of a direct call and now the error is gone. Though I don't
> understand it totally what was going on, it seems to me that this "handler
> loop" chocked itself somehow and got problems with the memory, like you
> pointed out.
> You saved my weekend :)
> Tiemo
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] Im Auftrag
> von Dar Scott
> Gesendet: Donnerstag, 2. Juni 2016 17:18
> An: How to use LiveCode <use-livecode at lists.runrev.com>
> Betreff: Re: LC 8 Random crash with QT set the filename of player on OS X
> 
> I don't think I have a very good understanding of your "loop".  
> 
> You seem to have some sort of recursion that will cause your call stack to
> grow and grow.  it looks as though 1 calls 2 which calls 1 which calls 2
> which calls 1 which calls 2 which calls....
> 
> At some point anything you do should cause a stack overflow.  This normally
> would create an error without a crash, but it might be that some operations
> assume space and will crash.  
> 
> If you don't intend the recursion, you might be able to break out the
> start-from-begining essentials of one command to be called by both commands.
> 
> 
> I'm just guessing here; I don't have a good understanding of what you are
> doing.  Since this runs fine on W10, I have a feeling that my guess is
> goofy.  
> 
> Dar
> 
> 
>> On Jun 2, 2016, at 8:38 AM, Tiemo Hollmann TB <toolbook at kestner.de> wrote:
>> 
>> Hello,
>> 
>> OS X 10.11.5, LC 8.0, IDE. Same program runs fine on Windows 10
>> 
>> I have a pretty nasty issue, where I am right now a bit clueless, in 
>> which direction I have to search. I have set the dontuseQT of  player
> "myPlayer"
>> to false because I am using old QT videos, which can't be played with AVF.
>> 
>> In a *videoPlay* handler I *set* the filename of player "myPlayer" to 
>> tVideoFile, which works fine in all situations and the video is played 
>> afterwords fine.
>> 
>> Now I have a pretty deep structure of handlers, as a kind of a loop 
>> with the modal userdialog and playing a video. The handler with the 
>> sheet/modal stack waits for some user interactions, calls the 
>> *videoPlay* handler and calls again the first handler, so that it 
>> starts from beginning. In the
>> *videoPlay* handler randomly this error occurs, when setting the 
>> filename of the player object.
>> 
>> 
>> 
>> A simplified structure looks like this:
>> 
>> command1:
>> 
>> *modal* stack myDialog
>> 
>>               command2
>> 
>> 
>> 
>> command 2:
>> 
>>               *set* the filename of player -> error
>> 
>>               command1
>> 
>>               *modal*stack myDialog
>> 
>> 
>> 
>> 
>> 
>> I have already tried to set a *wait" with messages before the *set* 
>> the filename, but it still crashes randomly.
>> 
>> As far as I can see, there are two main differences between the 
>> handler, where the issue occurs and where not. 1. The deeper structure 
>> of handlers and 2. The modal stack in between this handler "loop".
>> 
>> 
>> 
>> My feeling is that the engine choks somewhere in the "loop", but with 
>> different handler calls with/without *send* / *dispatch* I would 
>> probably mess up the "loop" structure.
>> 
>> 
>> 
>> Any idea, where to start?
>> 
>> Thanks
>> 
>> Tiemo
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 




More information about the use-livecode mailing list