Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ArgumentError in createVertexBuffer #1083

Open
j3k0 opened this issue Mar 8, 2021 · 14 comments
Open

ArgumentError in createVertexBuffer #1083

j3k0 opened this issue Mar 8, 2021 · 14 comments

Comments

@j3k0
Copy link

j3k0 commented Mar 8, 2021

This looks similar to issue #676, which is from 6 years ago but still open, so I kinda think I should post a new issue. It happens to a few users, I can't reproduce unfortunately.

ArgumentError: Error 3672
  ?, in starling.rendering::VertexData/createVertexBuffer()
  ?, in starling.rendering::Effect/uploadVertexData()
  ?, in starling.display::MeshBatch/syncVertexBuffer()
  ?, in starling.display::MeshBatch/render()
  ?, in starling.rendering::Painter/drawBatch()
  ?, in BatchProcessor/finishBatch()
  ?, in starling.rendering::Painter/finishMeshBatch()
  ?, in starling.rendering::RenderState/copyFrom()
  ?, in starling.rendering::Painter/restoreState()
  ?, in starling.display::DisplayObjectContainer/render()
  ?, in starling.display::DisplayObjectContainer/render()
  ?, in starling.core::Starling/render()
  ?, in starling.core::Starling/onEnterFrame()

The stack trace isn't "complete" in production, not sure if that can be improved. I will try to catch the error from createVertexBuffer to get more info, if someone has any idea in the meantime I'm interested.

@PrimaryFeather
Copy link
Contributor

Hm, the famous "Buffer creation failed. Internal error." ... Unfortunately, we were never able to pinpoint what's causing this. It would be helpful if Harman could maybe extend the error description – "internal error" doesn't give us a lot to work with. 😕

@j3k0
Copy link
Author

j3k0 commented Mar 9, 2021

I get an "ArgumentError" which might indicate arguments are not as expected in some cases? I'm trying this in hope to get better reports.

diff --git a/starling-2.6/starling/src/starling/rendering/VertexData.as b/starling-2.6/starling/src/starling/rendering/VertexData.as
index 5e19f8b..70015b9 100644
--- a/starling-2.6/starling/src/starling/rendering/VertexData.as
+++ b/starling-2.6/starling/src/starling/rendering/VertexData.as
@@ -901,8 +901,14 @@ package starling.rendering
             if (context == null) throw new MissingContextError();
             if (_numVertices == 0) return null;

-            var buffer:VertexBuffer3D = context.createVertexBuffer(
-                _numVertices, _vertexSize / 4, bufferUsage);
+            var buffer:VertexBuffer3D = null;
+            try {
+                buffer = context.createVertexBuffer(_numVertices, _vertexSize / 4, bufferUsage);
+            }
+            catch (e) {
+                throw new Error("createVertextBuffer(" + _numVertices + ", "
+                    + (_vertexSize / 4) + ", " + bufferUsage + ") failed: " + error.message);
+            }

             if (upload) uploadToVertexBuffer(buffer);
             return buffer;

@PrimaryFeather
Copy link
Contributor

That's definitely a good idea! You're right, perhaps the arguments are somehow not in an allowed range or something. Please let me know when you receive those logs — thanks a lot in advance!

@j3k0
Copy link
Author

j3k0 commented Mar 19, 2021

Got some data.

That's the error message now:

createVertextBuffer(288, 5, staticDraw) failed: Error #3672

It means:

  • _numvertices is 288
  • _vertexSize / 4 is 5
  • bufferUsage is staticDraw

In another instance: createVertextBuffer(4, 5, staticDraw) failed: Error #3672

Both cases have _vertezSize/4 = 5, maybe that's expected... but it looks like the calls are valid.

@PrimaryFeather
Copy link
Contributor

PrimaryFeather commented Mar 19, 2021

Thanks for the update, Jean-Christophe!

Hm, yeah, those look like rather conventional values. The vertex size is stored in bytes in Starling, but expected as 32-bit integer by Context3D, so that's why it's divided by 4.

The standard vertex format in Starling is position:float2, texCoords:float2, color:bytes4, which is 20 bytes or 5 four-byte integers. Exactly what we're seeing here.

@ajwfrost, is there any way to get more information about this "internal error"? Or would it be possible to add some more detail to this error message internally in Stage3D?

@ajwfrost
Copy link

Hi - so, "buffer creation failed" isn't in the initial parameter checking code. It means that the platform-specific creation of the vertex buffer hasn't worked properly..

What's the platform / driver mode? and is this reproducible for a particular app, or do you know if you hit this condition that you would get the same thing again if you just caught the error and re-tried?

I would guess we're getting an error from the graphics subsystem that we can't handle other than to just say "it failed".. if you can confirm e.g. what Direct3D version is used, etc, we can look at adding further debug info. Or perhaps we should just add something everywhere that this sort of thing could happen, to output a message to Scout?

thanks

@j3k0
Copy link
Author

j3k0 commented Mar 19, 2021

It happens on Android.

Error happens to multiple users, don't know enough about the device, except this:

  • Android / Linux 3.10.0-4756355
  • Android / Linux 3.10.17-1133823
  • Android / Linux 3.4.5

In the app's xml file, relevant sections:

    <renderMode>direct</renderMode>
    <android>
        <colorDepth>16bit</colorDepth>
        <containsVideo>true</containsVideo>

Please let me know how I can help more. I can instrument my app. I can share the stack trace from crashs we have on Android, as shown on Google Play Console. Quite a large number of crashs in libCore.so, but I assume it's not related because I believe I wouldn't get a report from AS3 if it was.

@ajwfrost
Copy link

@j3k0 if it's Android then it may just be an OpenGL issue with one of the calls being made to allocate a buffer that's not working properly.. not entirely sure what we could do to recover in these scenarios - is it a very graphically complex app that may be running out of GPU memory?

For finding out the root cause, judging by your above code and saying you're getting the error message information: we may be able to adjust that error code (or throw a different error with a more meaningful error), but are you also able to see logcat output i.e. we could also output more information to the log about the failure, prior to it hitting the 'throw' bit?

@j3k0
Copy link
Author

j3k0 commented Mar 21, 2021

@ajwfrost this isn't an error I could reproduce on our devices. It's happening to a few users: but for those there seems to be thousands of those errors. It may very well be that they ran out of GPU memory.

A way to access glGetError() from AIR would allow to add useful information to my error reports (or Starling's)

@ajwfrost
Copy link

Will see what we can do re that .. but initially, if you are able to see the output from the below snippet

           try {
                buffer = context.createVertexBuffer(_numVertices, _vertexSize / 4, bufferUsage);
            }
            catch (e) {
               throw new Error("createVertextBuffer(" + _numVertices + ", "
                   + (_vertexSize / 4) + ", " + bufferUsage + ") failed: " + error.message);
            }

then, would it help if we changed error.message so that it contained the root cause (or at least, the gl function and return code)?

@j3k0
Copy link
Author

j3k0 commented Mar 21, 2021

Sure, that would work fine.

If it's a little structured, like error.message = ...some text... (GL::<method>.<errorCode>) it would allow to do some regex magic.

What I'm looking at, if I can detect that it's a problem of GPU memory:

  1. Show a proper error message to the users: "Your device ran out of memory, the game might be unstable. You can try restarting your device, but maybe it is just too old, sorry!"
  2. If I can add figure out the total gpu memory of those users, prevent downloads from Google Play for those "low-ram" devices (I think it's possible). It will save some bad reviews.

@PrimaryFeather
Copy link
Contributor

Thanks a lot for having a look at this, Andrew!

Yes, I agree — having more information inside the error message would be ideal. From a support point of view, knowing that a device has run out of memory immediately allows ruling out all kinds of other logic errors. So adding more text, or, as you proposed, the internal GL return code, would be a huge help!

@PippoApps
Copy link

I have this error consistently launching AIR desktop Starling projects in the windows virtual machine on the MB Pro.
Same project running directly on Mac works fine. In my case is related to graphic card and vram.

@itlancer
Copy link

itlancer commented Nov 5, 2023

For me such issues (ArgumentError: Error 3672) fixed with latest AIR 50.2.3.7 if you using video playback on Android with Starling/Stage3D.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants