ID:2297819
 
Resolved
Reading/writing invalid filter vars could cause a crash. Additionally, the len property of the filters list was not accessible and caused the same crash.
BYOND Version:512.1387
Operating System:Windows 10 Home 64-bit
Web Browser:Chrome 61.0.3163.100
Applies to:Dream Daemon
Status: Resolved (512.1388)

This issue has been resolved.
Descriptive Problem Summary:
When multiple animate() calls are made or running simultaneously, Dream Seeker immediately locks up and crashes.

Numbered Steps to Reproduce Problem:
Don't use animate().

Expected Results:
Animate to work as beautifully as usual!

Actual Results:
Animate behaves like a trashy corner-trick.

Does the problem occur:
Every time? Or how often? yup
In other games? Yup, Kozuma confims
In other user accounts? Yup
On other computers? mmhm

When does the problem NOT occur?
When animate is called individually or sparsely, if at all.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? Worked fine on all builds prior.

Here's a gif of it crashing when some barrels explode:
Is there any way you can distill a demo that I can try this on? I want to find out if I can get the crash to happen myself, and if so what's causing it. It's possible it could be something as simple as the handling of filters for animation having a minor bug.
I'll get Kozzy to send his GiaD to you. He said it happens with it as well.
That'd be a big help; thanks.

Does that happen with projects predating 512 or is it only in cases where a filter is in use? I see in your example .gif that you're already using outlines.
This just started with 512.

And I just checked and it crashes without filters also.
Thanks. That's helpful info. I'll see if Kozuma's project gives me any leads.

[edit]
Oh, quick question: Is it possible to determine whether the server or the client is crashing? My guess is the client but I'd like to know for sure.
Kozuma's lead might be a dead end, so I'll need something to test with.
Working on it now! And i have no clue, i have narrowed it down a bit though. I'll have something for you shortly.
Well, my attempts to replicate the issue aren't proving fruitful. I'll keep at it, but it seems like a very specific-case issue.
Whenever you get something together, just let me know. Obviously this is a high-priority fix.

It would be very good to know if it's the server or client. And also, is this an actual crash or is it a hang?
I assume it's client, but idk for sure.
And it's an actual crash. No errors or anything though.
It seems to be a client-side crash, I think I can confirm. My project is using Animate() alot too, and crashes when I try to run it.

However, Dream Daemon is telling me the server is running. After trying to join the server after hosting, it seems fine and intact after the client crash.
Does the crash happen for you right away, Ginseng? If so it would be helpful to have the source.
It does, yes. The source is quite large though, so I couldn't really say where exactly the crash might be happening either.

Do you want me to send it to a specific email at all?
Might work better to put it up somewhere I can download it and just send me a link. Your Member file space would do; just upload it as visible, not hidden, and give me the link, and I'll let you know when I have it so you can delete it.
Okay, so I have an update on this. I found a couple of issues, and I'm still not out of the woods yet.

First issue: Reading the len var from the filters list was not handled properly.

Second issue: The error message from the first issue was not handled properly (this happened in multiple places), and that was causing the crash.

Now I'm having a very bizarre and predictable crash that happens as an apparent result of heap corruption. So I'm trying to figure out why that might be. I've confirmed filter animation is NOT responsible, which is a good start, but I haven't managed to solve the rest quite yet. It does appear to at least be filter-related, but beyond that I'm still not sure.
Don't you mean, BYOND that you're not sure? (^8
Just a brief update on this. While this does appear to be heap corruption, it's been so remarkably consistent that I've had a leg up in trying to get to the bottom of the problem.

Kumo, I've narrowed this down to the light_fuse() proc you pointed out. If I lose the animate() calls in that routine, I don't get the heap corruption crash. Changing the calls doesn't do a darn thing, even removing the looping, but I did find that if I altered the animation to mess with color instead of transform, there's no crash. And the crash, when it does happen, consistently happens when I shoot a bunch of barrels; the easiest way to trigger it is to go left on the Streetwise map and shoot the barrels there.

While I haven't figured it out yet, I'm getting there.
In response to Lummox JR
could it have anything to do with the Explode() call in light_fuse() being under a call stack from another Explode() proc ? probably a far fetched idea, but that's about all i could theorize. I'm not a wizard.
Well, one thing I did discover was that when the crash happens, the animation is underway even if I turned off the loop and made it super short. This suggests to me that light_fuse got called more than once on the same object, although I can't guarantee that the object causing the problem is in the process of exploding. I'll get more data on this tomorrow.
Page: 1 2

Login to reply.