TypeError: Cannot read property 'length' of undefined



  • 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.