Possible timer object problem

[Mark F]

I've been using the gir.CreateTimer() interface to build some completion routines (start the function now, the timer completes it later).

It appears the LUA mutex may not be released after the LUA code runs (due to an expired timer). If I use a timer to run LUA code, my serial plugin :) thread cannot acquire the LUA mutex, ever. If I don't use the timer object, I have no problems acquiring the mutex.

Could you take a look at this for me?

[Ron]

Hmm I can't see this one. I only aquire the mutex once and I do let it go, also when I test with a timer running and then canceling it, I can still use the interactive lua console (which also uses the mutex).

What code are you using inside the timer?

[Mark F]

If I run the following, my plugin cannot acquire the LUA Mutex, ever. Also, Girder will not terminate when I use File/Exit.


TimerObject = gir.CreateTimer("","TimerObject:Destroy(); TimerObject=nil","",0)
TimerObject:Arm(500)


If I use the following, it works fine.

TimerObject = gir.CreateTimer("","TimerObject=nil","",0)
TimerObject:Arm(500)

[Ron]

Mark you always surprise me :-) Doing things I didn't think of. I will see why calling destroy messes up things.
Thanks

[Ron]

Side note, you do not need to call Destroy, the GC cycle will clean up too.

[Mark F]

:)

I take it I don't need to call Destroy() if I am going to set the global variable to nil? In the WinLUAEx code, this allowed the thread resources to be released before a garbage collection occured, sometime later.

In any case, I'll leave it the way I have it (=nil without a Destroy) until you tell me otherwise.

EDIT: Cross post. I will leave it alone forever. :)

I have the RemotePoint Plus remote control working using the serial plugin on G4A6. :D There is no UI for the plugin. All the configuration code and data parsing is written in LUA. I may change this in the future.

I had a fruitful weekend. ;)

[Ron]

Great news Mark! I'll let you know if I find the culprit.

[Ron]

Mark are you still using G4-a6 on the win98 machine? Just wondering if it runs stable for you (it seems to be stable here, unwrapped that is).

[Mark F]

Yes, I am still running the unwrapped version. It only crashes about once in every 6 times I run it. This could be caused by the serial plugin, though. I haven't fully investigated as I was more worried about getting the plugin code figured out.

On a separate note, when I start the wrapped version on XP under visual studio (debugging the plugin) I get about 200 error, soft traps, etc. type messages. Most of the time it still runs but sometimes I get a bad error box that asks if I want to send you an E-Mail.

[Ron]

The errors with number 0x0EEDFADE are delphi exception, even though I handle them they still reach Visual Studio. The others C00005 errors are Armadillo erros (since they are not present without the wrap). Next time it asks you to email me a bug report please do so and let me know what you where doing. I put that debug reporting thing in there.

[Ron]

In good programmer fashion I eliminated those exceptions. :-) Note to bystanders this was not affecting the application.

[Rob H]

In good programmer fashion I eliminated those exceptions. :-)

BTDT :)

[Ron]

BTDT?

[Ron]

Duh, Been There Done That. 8)

[Rob H]

Yup :)

BTDTBTTS

[Ron]

Here is a brain teaser :-)

1. An imaginary application generates a General Protection Fault when protected with Armadillo.
2. The GPF happens during the DLL-loading phase of the app - startup.
3. Armadillo is generating tons of C0000005 ACCESS VIOLATION in the debugger
4. The GPF dialog is on screen, yet the loading of this imaginary app still continues, and in fact it works, if it wasn't for windows going down soon thereafter.
5. The app seems to work without the wrapper.

Someone got any ideas on where to look? Since Girder actually startsup the GPF doesn't seem to be inside of Girder, A GPF shuts an app down right?

[Rob H]

Is this only under the debugger?

If it is then Armadillo is probably doing it deliberately to prevent hacking.

[Ron]

the crash happens with and without debugger.

[Rob H]

Can't think what to suggest then. One for the guys who wrote Armadillo I guess.

[Ron]

Yeah that is what I thought too. They don't think so.

[Rob H]

What happens if you take madExcept out?

[Ron]

grumbl. :evil: you don't want to know. (it seems to work now)

I tried this before but I must have missed one of the dlls. More testing to make sure.

[Ron]

It's fileio.dll, when I add MadExcept to that one the thing crashes under Win98 if Armadillo is protecting Girder. Lovely. Who suggested MadExcept again :lol:

[Rob H]

:)

Might be worth talking to Mathias about this. Are you using the latest madExcept? Current version is 2.7g

[Ron]

Yeah I updated and the bug is still there, I was about to send him an email.

[Ron]

@ Mark, sorry for hijacking this thread, your orginal bug has been fixed.

[Mark F]

I enjoyed the conversation. :) Thanks.