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

Emulator fails with out of memory error #3270

Open
igor-everybuddy opened this issue May 29, 2024 · 5 comments
Open

Emulator fails with out of memory error #3270

igor-everybuddy opened this issue May 29, 2024 · 5 comments
Labels

Comments

@igor-everybuddy
Copy link

Hi,

When I run mobile application in emulator, it fails with message: "error: out of memory".

Problem Description

Describe your problem in detail. Include the following information:

  • Which AIR SDK did you use?
    AIR SDK:33.1.1.300, 50.2.5.1, 51.0.1.1

  • Environment:
    Microsoft Windows 11 Pro, Version: 10.0.22631 Build 22631, System type: 64 bit
    Laptop: Lenovo IdeaPad Gaming 3 i7-12650H
    Processor: Intel Core i7-12650H 2300 MHZ, 10 Cores, 16 Logical processors
    RAM: 64GB
    Video card: NVidia GeForce RTX 3050 Laptop GPU

  • Can you reproduce it yourself, or did you get reports from other users? If so, how many users are affected (percentage)?
    Myself.

Steps to Reproduce

I run my application by next command line:

adl.exe -profile extendedMobileDevice -screensize 534x950:534x950 -XscreenDPI 326 -XversionPlatform AND C:\projects\slotagram_starling\webapp\flex\slotagram-mobile-boot2\target\slotagram-mobile-boot-app-android-localdev.xml C:\projects\slotagram_starling\webapp\flex\slotagram-mobile-boot2\target

After it application starts and begin to receive bitmaps from server and create a textures for them and during it the application crashes with message: "error: out of memory".

Give us a minimal example:

  • As little code as possible. Get to the root of the problem!

Looks like following peace of code is a last one before fail:

            if (logger.isDebugEnabled()) logger.debug("Asynchronously uploading ATF to GPU: " + _name);
            var callToAtf_start:int = getTimer();
            Texture.fromAtfData(atfByteArray, 1, false, handleAtfTexture);
            if (logger.isDebugEnabled()) logger.debug("Asynchronously uploading ATF to GPU after Texture.fromAtfData: " + _name);

   private function handleAtfTexture(texture:Texture):void {
        if (ScriptingUtils.notifyAspectWithParams("TextureAtlasGpuUploadTask.handleAtfTexture", this, texture)) {
            return;
        }
        _texture = texture;
        var duration:int = getTimer() - _startTime;
        _atfTotalCount += duration;
        _atfTotalCount++;
        var u:String = (_async ? "Asynchronous" : "Synchronous");
        logger.info("Successfully Uploaded " + u + " ATF to GPU: " + _name + " " + "   time:" + duration + " (total=" + _atfTotalTime + " count=" + _atfTotalCount + ")   #atf - " + duration);
        if (ScriptingUtils.notifyAspectWithParams("TextureAtlasGpuUploadTask.handleAtfTexture.after", this, texture)) {
            return;
        }
        // Done
        completeTask();
    }
  • Include all necessary files (e.g. textures).

Below is attached archive with three logs of my application and three windows application crashing events from windows eventviewer, each pair per different versions of Adobe Air SDK: 33.1.1.300, 50.2.5.1, 51.0.1.1, and archive with my application descriptor

logs.zip

application-descriptor.zip

@ajwfrost
Copy link
Collaborator

That generally means that the app is unable to recover from a low memory situation i.e. where we've asked for a new region of memory (via the Windows "VirtualAlloc" call) but it's failed to return us anything, and the memory request had been considered to be crucial. So the runtime just aborts..

FYI we have a few changes going in to 51.0.1.2 because of this sort of thing though:

  1. updates to avoid some instabilities that were happening during the OOM shutdown process..
  2. correction to build flags to allow VirtualAlloc to allocate more memory than before, which may mean you no longer hit OOM situations

But it's worth keeping an eye on your allocations and making sure you e.g. dispose of any bitmap data or byte arrays properly...

thanks

@igor-everybuddy
Copy link
Author

Hi @ajwfrost , thank you for an answer, is it known when 51.0.1.2 planed to be published?

@ajwfrost
Copy link
Collaborator

Should be available first thing tomorrow..
thanks

@igor-everybuddy
Copy link
Author

igor-everybuddy commented May 30, 2024

@ajwfrost
If I've got you correctly from previous comment for my case more relevant the second thing is that known when it will be ready?

@ajwfrost
Copy link
Collaborator

Both the changes I mentioned will be out in 51.0.1.2, so that should definitely help with your application...

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

No branches or pull requests

2 participants