Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 5 of 5

Thread: OOM Errors with ample memory on Teensy LC

  1. #1

    OOM Errors with ample memory on Teensy LC

    Hi guys, I'm running into a strange issue where after upload, my Teensy LC becomes unresponsive seemingly due to out of memory errors, even though my data usage is well within the limits.

    For example:

    I have an data array with 5 values; on upload, the data usage is calculated as follows:

    DATA: [===== ] 54.3% (used 4448 bytes from 8192 bytes)
    PROGRAM: [==== ] 40.9% (used 25996 bytes from 63488 bytes)

    When I compile and upload, all of my serial.print lines work fine and the program works great.

    If, without changing anything else, I increase the size of my array to hold 6 values, the data usage is calculated as such:

    DATA: [====== ] 57.8% (used 4736 bytes from 8192 bytes)
    PROGRAM: [==== ] 41.0% (used 26004 bytes from 63488 bytes),

    But my program is unresponsive.

    Are the calculated memory usages not indicative of what's happening at runtime? Is there any way I can see where i'm at during runtime with memory usage?

  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,920
    Without seeing code … speculation is that the array increase is resulting in creating or exposing array index handing errors, that is data is written outside the allocated array space?

    Perhaps :: there was an error indexing beyond the array boundaries - but it didn't fail because it wasn't trashing anything critical

    OR:: the array extension was not properly accounted for everywhere

  3. #3
    To test this out, I created a separate variable outside of the array, which functionally would occupy the same amount of memory..

    For example:

    Datatype array[5]
    Datatype memoryPusher

    Should have the same effect as:

    Datatype array[6]

    Without the possibility of handling errors. The same behavior persists...

  4. #4
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,920
    Quote Originally Posted by vince.cimo View Post
    To test this out, I created a separate variable outside of the array, which functionally would occupy the same amount of memory..

    For example:

    Datatype array[5]
    Datatype memoryPusher

    Should have the same effect as:

    Datatype array[6]

    Without the possibility of handling errors. The same behavior persists...
    That seems logical - but not sure there is a rule or expectation that the allocations would in fact be done that way through compiling and linking. Or the problem could be more than an off by just ONE error?

    Also Datatype indicates an unknown structure? So errors may be within structure elements as there is no idea what is in there in the form of fundamental types or arrays or ???

  5. #5
    Hmm yeah the reason I left it generic is because it's a custom datatype.

    Here's the actual initialization causing issues:
    (if I change NUMBER_COMMANDS from 5 to 6, hell breaks loose)

    DLCommand commands[NUMBER_COMMANDS];

    The DLCommand class:
    Code:
    class DLCommand {
    
    	public:
                    DLCommand();
                    DLCommand(uint64_t command, DLled * _led, unsigned char _buttonNum, DLObserver * _dataLooper);
                    DLObserver * dataLooper;
                    DLled* led;
                    unsigned char * state;
                    bool toggle = false;
                    void sendSysEx(); 
                    void execute();
                    void checkLed(bool onOff);
                    void checkDLCommands();
                    ee_storage_typ ee_storage;
    };
    The ee_storage_typ class:
    Code:
    typedef union
    {
    		commands_typ commands;
    		uint8_t asBytes[BYTES_PER_COMMAND];
    		uint64_t the_big_blob;
    } ee_storage_typ;
    The actual implementation code inside DLCommand.cpp is super benign and should have any errors on initialization of new variables. I'm pretty sure this is memory related.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •