Crashing Issues...

06-24-2006, 05:48 PM	#1
Sharingan	When or why would WC3 crash while using Timers and Handle Vars?

06-24-2006, 06:04 PM	#2
Jacek	Well... for example I guess it would crash when you'll try to start a destroyed timer... -.-

06-24-2006, 06:10 PM	#3
vile	Another possible crash is not pausing the timer before destroying it, when destroying it not in the timer's function, but rather from another function.

06-24-2006, 06:10 PM

Rising_Dusk

It's a weird bug that occurs every 6th or random amount of usages of a timer with handles attached to it.
It's happened to me when it's nulled and even when it isn't nulled, so I really can't explain it.

It's just a bug, that's really all it is.
However, I recommend not worrying about it unless it starts happening, then you should just not null the timer. That usually seems to fix it.

Vex also had some sort of wrapping function that goes back and deals with the situation, I'm sure when he sees this post he'll show it to you (Or someone else familiar with it).

And yeah, pausing a timer before destroying it is important if in another function.
Don't forget that. (Thanks for reminding, Vile)

06-24-2006, 06:16 PM	#5
Jacek	Hmm I never paused my timers :\| and my spells didn't crash... I guess I was lucky then

06-24-2006, 07:22 PM

Sharingan

Quote:

Originally Posted by Rising_Dusk

Exactly, it happens randomly...which makes it highly sad...
Now, are you saying that I must not nullify any local timer variables?
Wouldn't this create lot of leaks?
...Actually, I only used ExpiredTimers in other functions, so pausing the Timer won't do any difference.
But now, I removed the nullifying, but it still happens randomly.....

06-24-2006, 07:28 PM

Rising_Dusk

You can nullify timers wherever it does not occur.
Also, be sure it is not forgetting to pause a timer first, that usually fixes most of these errors.

Once you're sure it's a handle error, follow these instructions as written by Blade.dk:
Do note, all of the following 3 methods will deal with the problem.
==========================

Quote:

The ”Setting variables to null when using the return bug” - bug

In very rare situations, setting a variable (most often a timer) which content’s you use with the return bug can cause problems. It seems like it sometimes resets the object’s handle id.
There’s multiple solutions to this:

1. Don’t set the variable to null. This is the easiest solution, but it will cause (very minor) memory leaks.

2. Lastly, you can temporarily use a global variable to store the object in.

3. Use another function that takes a timer (or whatever other type you have the problem with) value. You can pass the value null to that function, and simple use the parameter as variable, as it does not need to be set to null. Example:

JASS:

function X2 takes timer t returns nothing
    call DoSomethingWith(t)
    call DoSomethingElseWith(t)
endfunction

function X takes nothing returns nothing
    call X2(GetExpiredTimer())
endfunction

...
call TimerStart(yourTimer, duration, periodic, function X)
...

06-24-2006, 08:26 PM	#8
The)TideHunter(	nulling timers when they are counting also bugs. Nulling and destroying timers before they have finished without pausing dosent crash the thread, but can have weird side effects. Also, in the Handle Var side, if your making them yourself, and your using HandleToString, then that will definatly cause a crash, strings arnt typecastable

06-25-2006, 12:51 AM	#9
PipeDream	http://www.wc3campaigns.net/showthread.php?t=81872 Personally I prefer heavily abusing the return bug. Keep the timer in an integer and use ItoTimer whenever you need it as a timer.

06-25-2006, 06:13 AM	#10
vile	Well, Vex said in a thread that it does crash sometimes when you dont pause the timer, after he tested it. I also had crashes because of this.

06-25-2006, 06:28 AM	#11
PipeDream	yes, here. http://www.wc3jass.com/viewtopic.php?t=2373 You should pause before destroying _and_ avoid changing the value of the timer variable.

06-25-2006, 10:32 AM

#12

Sharingan

He is saying that a timer would be expiring after destroying it.
Now do I have to pause it even if the timer is already expired? BTW, I still crashes even if I pause anyway, so it is a problem of Handles...

Quote:

Originally Posted by PipeDream

http://www.wc3campaigns.net/showthread.php?t=81872

Personally I prefer heavily abusing the return bug. Keep the timer in an integer and use ItoTimer whenever you need it as a timer.

I will check this out, but why would this do any different?

06-25-2006, 10:48 AM

#13

The)TideHunter(

Quote:

Originally Posted by PipeDream

yes, here. http://www.wc3jass.com/viewtopic.php?t=2373
You should pause before destroying _and_ avoid changing the value of the timer variable.

Ah, im mistaken.
I'v never used tables before, so i'v never come accross the problem.
I always just thought destroying/nulling a timer before its expired made the game buggy =/.

06-25-2006, 11:42 AM	#14
PipeDream	If you have a specific crash please post code and the error log from Warcraft III\Errors This has little to do with the table abstraction.