Javascript Uncaught Abort Crash Physics_behaviour.js

Bugs will be moved here once resolved.

Post » Fri Nov 06, 2015 4:11 am

Message: Fengist is not yet permitted to post plain text URLS (300 rep required). 1 URLS removed. Why?
Problem Description
____ A concise description of your problem here ____
Simply running this layout causes a Javascript abort at an uncaught error. The layout attempts to create 50 sprites. Within 1 minute, it usually will crash. No user interaction required.

Attach a Capx
____ Upload a Capx to this post ____
Description of Capx
____ Concise description of what this CapX does ____
Very simple 8 event capx. First, creates a procedural background from a sprite animation and an array (from a tutorial on this website). Second, creates a parallax background in the same manner. It starts with one 'user' sprite that's mouse controlled. Every 3 seconds, it creates a new 'sprite3' (up to a maximum of 50) and then applies a random physics force to all 'sprite3'.

Steps to Reproduce Bug
  • Step 1 Run the layout.
  • Step 2 Wait.

Observed Result
____ What happens? ____

A popup notifiying the user of a 'Javascript Abort ()' error.

Expected Result
____ What do you expect to happen? ____

To not crash???

Affected Browsers
  • Chrome: (YES)
  • Internet Explorer: (YES)
  • Edge (YES)

Operating System and Service Pack
____ Your operating system and service pack ____

Windows 10

Construct 2 Version ID
____ Exact version ID of Construct 2 you're using ____

Release 216 64 Bit


Sorry if this has been reported before or if I'm somehow doing something wrong. I've only been using Construct 2 for 2 days.
B
16
S
8
Posts: 127
Reputation: 1,928

Post » Fri Nov 06, 2015 4:17 am

And it cut out my url:

w*w*w.datainterlock.com/Construct/Javabug.capx

And here's the java console output.

Code: Select all
Uncaught abort() at Error
    at Error (native)
    at fb (http://localhost:50000/Physics_behavior.js:31:26)
    at ua (http://localhost:50000/Physics_behavior.js:417:61)
    at Function.h.o [as W] (http://localhost:50000/Physics_behavior.js:17:91)
    at nc (http://localhost:50000/Physics_behavior.js:167:483)
    at NB (http://localhost:50000/Physics_behavior.js:196:40914)
    at mo (http://localhost:50000/Physics_behavior.js:184:88231)
    at j.O (http://localhost:50000/Physics_behavior.js:734:21)
    at createPolygonShape (http://localhost:50000/Physics_behavior.js:818:17)
    at behinstProto.createBody (http://localhost:50000/Physics_behavior.js:1734:24)
If this abort() is unexpected, build with -s ASSERTIONS=1 which can give more information.c @ Physics_behavior.js:7ua @ Physics_behavior.js:417h.o @ Physics_behavior.js:17nc @ Physics_behavior.js:167NB @ Physics_behavior.js:196mo @ Physics_behavior.js:184O @ Physics_behavior.js:734createPolygonShape @ Physics_behavior.js:818behinstProto.createBody @ Physics_behavior.js:1734behinstProto.tick @ Physics_behavior.js:1888Runtime.logic @ preview.js:2573Runtime.tick @ preview.js:2322tickFunc @ preview.js:649
Physics_behavior.js:10 Cannot enlarge memory arrays. Either (1) compile with -s TOTAL_MEMORY=X with X higher than the current value 33554432, (2) compile with ALLOW_MEMORY_GROWTH which adjusts the size at runtime but prevents some optimizations, or (3) set Module.TOTAL_MEMORY before the program runs.
Physics_behavior.js:10 Cannot enlarge memory arrays. Either (1) compile with -s TOTAL_MEMORY=X with X higher than the current value 33554432, (2) compile with ALLOW_MEMORY_GROWTH which adjusts the size at runtime but prevents some optimizations, or (3) set Module.TOTAL_MEMORY before the program runs.
B
16
S
8
Posts: 127
Reputation: 1,928

Post » Fri Nov 06, 2015 8:46 am

@Fengist

I'm on Windows 7 and I've tested this in FireFox 42.0, IE11 and NW.js and it works on all 3.

At what point is it meant to crash?
If your vision so exceeds your ability, then look to something closer.
Moderator
B
137
S
31
G
87
Posts: 5,548
Reputation: 60,440

Post » Fri Nov 06, 2015 11:49 am

There is no specified point. I let it run for about a minute or two and it crashes.

I found this post with a response from Ashley: w*w*w*.scirra.com/forum/viewtopic.php?f=151&t=148526
which is a link from this post: w*w*w*.scirra.com/forum/physics-behavior-js-app-crash_t148047
which produces the same error I'm having. Apparently me creating objects and changing physics on the fly is causing the crash. Unfortunately, I've had it crash with as few as 20 objects.

While I program in several languages, I'm a complete noob at Construct. But that seems like a huge limitation. And right now, I'm not sure what a workaround would be. What I was planning on was 20-50 physics objects floating around that randomly change directions, bounce off each other, etc.
Last edited by Fengist on Fri Nov 06, 2015 12:00 pm, edited 1 time in total.
B
16
S
8
Posts: 127
Reputation: 1,928

Post » Fri Nov 06, 2015 11:57 am

The bullet behavior might be an alternative option to try while waiting for a response. It has a property that allows it to bounce of other objects.
If your vision so exceeds your ability, then look to something closer.
Moderator
B
137
S
31
G
87
Posts: 5,548
Reputation: 60,440

Post » Fri Nov 06, 2015 12:04 pm

Thanks zenox, I just thought of that myself and changed those objects to bullets. The good news, it hasn't crashed yet. But in my ignorance though, they don't seem to bounce off each other or the boundary walls and they pass right through the one physics object I left. Plus, random motion looks pretty stiff.

If this is the route I'm going to have to go it looks like I'm going to have to create a lot more events to handle collisions and 'simulate' physics.
B
16
S
8
Posts: 127
Reputation: 1,928

Post » Fri Nov 06, 2015 12:18 pm

Tried again and left for a while - also ran in debug - and it does throw the error. It's interesting to watch the number of sprite3 creations as, for me, it created more than 50 before crashing. Changing from the variable check to sprite3.count seems to stop it going over 50, but it still crashes.

It's going to need a more qualified eye than mine, I think.
If your vision so exceeds your ability, then look to something closer.
Moderator
B
137
S
31
G
87
Posts: 5,548
Reputation: 60,440

Post » Fri Nov 06, 2015 12:25 pm

While the number of sprites does have an effect, I'm pretty sure it's where I'm applying the physics every 3 seconds. Usually for me, about the time it's hitting 50 is when it crashes. But, if you set the number to 20 and let it keep running, it'll still crash, just takes longer. Setting the event timer to something like 1 second may make it crash sooner.
B
16
S
8
Posts: 127
Reputation: 1,928

Post » Fri Nov 06, 2015 3:07 pm

Ok, I did some more testing.

First, instead of creating the sprites every few seconds, I created 100 of them in a for loop in the On Start of layout event. It loaded them up fine and they started animating. After about 30 seconds, it crashed. So, creating them with a timer or all at once isn't a factor. But I thought it odd that it was able to create all of them and to run for 30 seconds before crashing. It 'feels' like a memory leak.

So, I wondered what the minimum was I could create and have it crash. While I haven't tested any lower than this, I changed the for loop to create just 5 of the Sprite3. Without applying any force, not moving the mouse, nothing... it took about 10 minutes but it crashed. So, a total of 6 sprites with the physics behavior enabled caused the JS to crash.

While, as I mentioned, this sounds like a bad memory leak, if this is a result of the memory limitation that Ashely increased, and if just 6 physics sprites reaches that limitation, then that's REALLY limiting what this game engine can do. And crashing is a really, really bad way of letting the developer know they've reached that limit.

I do hope this isn't working as intended. I have high hopes of purchasing this engine and putting it to good use.
B
16
S
8
Posts: 127
Reputation: 1,928

Post » Fri Nov 06, 2015 6:05 pm

@Fengist
It doesn't crash for me either, and I'm not sure why you'd be running into a memory limit with asm.js in your capx.
One thing that does stand out is sprite3 is animated. The physics engine has to re-calculate the collision polygon every time the frame changes, which I guess may be using up memory. Often what I do is create an invisible second object with one frame to handle the physics, and then remove physics from the animated object and pin it to the other object.

Also you can avoid the memory limit entirely by changing "project properties"->"Physics engine" from "asm.js box2d" to "box2d web". The only difference is the performance may not be as good.
B
94
S
33
G
118
Posts: 5,393
Reputation: 75,847

Next

Return to Closed bugs

Who is online

Users browsing this forum: No registered users and 2 guests