3. TypeError: Cannot read property 'length' of undefined

TypeError: Cannot read property 'length' of undefined


  • I get this message periodically on the console, in red with no traceback, similar to when it tells me I ran out of time. It was happened a LOT this morning after the servers being down; I think it is associated with running out of time, but I'm not sure how.

    Note that essentially all my code is inside various try/catch blocks, so normally any error other than time-limit is caught and printed with a stack trace on the console, not in red.

    The one time I saw this same type of error, and was able to track it down, it was due to my stuffing an entire creep into Memory instead of just the RoomPosition.

    Is it possible that if execution expires at the wrong moment, Memory is somehow being screwed up and causing this? Or could it be something I'm putting into Memory that I shouldn't?

    Without a stack trace it's almost impossible to debug, considering that it seems to happen at random (I haven't found a way to cause it to happen continuously).

    Anyone else seen something similar?


  • Oh, I should also note -- when this occurs, there is no other console output for that tick, and it appears that no commands are executed.


  • Yes and its happening a lot, as described here in a confusing way (I was digging into it, and didn't know the cause then)... http://support.screeps.com/hc/communities/public/questions/201198312-Mysterious-error-without-stack-trace

    I'm assuming now that if an error doens't match a certain type of message, it simply throws e.message where e.stack would actually provide more information about where the error has happened. That would ease fixing by having more accurate information...


  • After some more investigation, I am beginning to strongly suspect that this occurs when you run out of execution time during encoding of Memory at the end of the tick.

    That's something that is difficult for me to prove or troubleshoot further, but it ought to be easy for the developers to check on; if that's the case, I expect it's just an error condition they entirely forgot to handle, and will happen reliably every time a player runs out of CPU during Memory encoding.


  • You're probably right about it being an error with Memory encoding. I've noticed that it started popping up when I started using more memory, and the error also empties the Memory bar in the upper right.

    I guess the best we can do right now is to use less and hope for the best. >_<


  • OK, I think I tracked this down once and for all, it was in my code all along. The timeout correlation was because when CPU was tight, I cranked down maxOps, which would result in findPath returning undefined, which I tried to check the length of. Or maybe it was that the timeout threw as an error in my try block around findPath, and then same thing immediately following. Anyway, changing path.length to path && path.length seems to have completely eliminated these errors.

    The mystery is why I wasn't getting a traceback. I found this because I eventually did get one, because what was different I'm not sure.

    Possibly relevant is that this is all occurring inside a method I wrote to override the default moveTo; I'm not sure if you're supposed to do that or not, or if it contributed to the lack of traceback.


  • That's kinda strange; I ended up checking all instances of .length in my code and making sure that none of the instances were undefined. In the end, clearing out some stuff in the memory banks made the error stop popping up.


  • Noooooo...it's back. Alright, I have no fucking idea. If only we could get a stack trace for this!!!


  • Lol, how much memory are you using? I doubt that an error with your code would ever go without causing a traceback. It's probably either the memory or something weird with the new runtime engine.


  • I'm using around 700KB at the moment. Last I benchmarked it, JSON.stringify on Memory was taking 12-15ms. These values don't seem to be substantially different when the problem is occuring, sometimes in solid bursts of 20-40 ticks at a time.


  • Oh, I've never thought of using JSON.stringify. I guess it's so fast, all the cool kids are doing it 😮

    Anyways, I restarted and am currently redoing my scripts, so I'm thinking of just limiting the amount of rooms and creeps I'm gonna use. It seems better than all my creeps moving at half-speed because of constant errors, for now.


  • This can definitely be caused by a call to lookAt(). I've got it narrows down to a spot where if I lookAt() a particular thing, then return, it crashes every time, vs if I just comment out the lookAt() before the return, everything is peachy.

    I'm still trying to figure out exactly which parameters to lookAt() cause the issue; there's no easy way for me to tell which one is causing the crash.


  • Eureka! This error essentially means "timeout during lookAt". Reproduce as follows:

    while (true) {
    Game.rooms.W5N4.lookAt(25, 25);
    }


  • ...That's really weird. I haven't been able to reproduce the error in W8N4, though. Have you tried the same code in other rooms?


  • Works for me in any room where I have creeps. Works from the console. Works if my script is otherwise empty. I can't find a way to make it not work, for me.


  • Well, you can just paste for(;;){} (or some other code that triggers an infinite loop, for that matter) into the console, and the exact same error will pop up.


  • Gah. Well, ummm..at least this verifies it is related to running out of CPU time, not some other cause?

    It would be nice to instead get the promised behavior of prior commands being executed and prior script output being shown, when you hit the CPU limit. I've seen that work properly in circumstances (of unknown nature) when the normal message instead of this one appeared.

  • Dev Team

    Thanks to all for reporting this and good reproducing work. Fixed.