Out of range write in DEBUG build...

#1 Btw., here is the console output...

Starting multiplayer mode
*** LOADING MISSION: fps/data/missions/pca_first_contact.mis
*** Stage 1 load
*** Stage 2 load
Executing fps/data/missions/pca_first_contact.mis.
*** Mission loaded
CADD: 1468 local
*** Sending mission load to client: fps/data/missions/pca_first_contact.mis
Sending heartbeat to master server [IP:216.116.33.156:28002]
*** New Mission: fps/data/missions/pca_first_contact.mis
*** Phase 1: Download Datablocks & Targets
Fatal: (f:\tork\torque\engine\core\bitstream.cc @ 179) Out of range write

Happens with every mission file, though...

#2 Maybe one of the resources I've integrated is making a problem?
Basically, they are:
- Inventory Manager by Tim "Spock"
- Hiding Nodes by Frank B.
- Lens Flare
- fxShapeReplicator
- fxLight
- Frank's MapGui
- DTS viewer
- Landscape preview
- Cpt. Fallout's RadarGui
- JetPackLove
- Melv's water enhancements
- Ogg Vorbis support

Anybody else put them in and got DEBUG mode running?
I think the only one changing "core" stuff like bitmasks is "Hiding Nodes", may there be a problem? Any thoughts?
What really bugs me is that it's working in RELEASE builds...
Thanks for any tiny, little idea where to start looking... :-(

#3 you'll need to debug I would say..
and check the callstack to find out which object has caused the problem...

#4 Mhm, okay, so I'm going to debug the DEBUG when I'm back home ;-)
Thanks! I'll let you know what I get there...

#5 Hi,

we also had to fix this bug. The problem is a buffer overflow. Just change this in /game/gameConnectionEvents.cc:

void SimDataBlockEvent::process(NetConnection *cptr)
{
      :
      :

      if (Sim::findObject(id,obj))
      {
         U8 buf[1500];
         BitStream stream(buf, 1500);

            :
            :

      }

      :
      :
}

TO:

// --- bit stream crash fix: increased buffer size from 1500 to 2000
#define BITSTREAMSIZE 2000

void SimDataBlockEvent::process(NetConnection *cptr)
{
      :
      :

      if (Sim::findObject(id,obj))
      {
         U8 buf[BITSTREAMSIZE];
         BitStream stream(buf, BITSTREAMSIZE);

            :
            :

      }

      :
      :
}

cu
Felix

#6 I'll try it as soon as I'm home!! Thanks very much!!!
Would be GREAT if it solves this... :-)

EDIT: Just curious - anybody knows why it works in the release build then?

#7 Thanks again!!! That really solves it!! I owe you a beer, I guess ;-)

#8 Stefan, asserts only pop dialog boxes in debug mode. The overrun was still happening in release mode, it just wasn't throwing an error message.

#9 I had the same problem but this solves it..

thanks..

#10 Wow, big bump, actually this helps me too :) so thanks

#11 Why hasn't this been increased in the head by now? Is there a reason its set to 1500? I've run into this error before but due to code changes it moved to line 181 and it took too long to find this thread, lol.

#12 It could it be connected to MTU size or maybe it was just big enough at the time?

I know I was having trouble with something like this at one point when I had a bunch of animations and the array of sequences was bigger than 1500 bytes. Now my app was single-player so it wasn't a problem to increase the buffer size and short-circuit it in other ways.

$.02 I think a "better" approach might be to see why you're blowing the buffer and see if you can optimize it there...

#13 The fix above doesn't work for me on missions where I have lots of objects. Is there another reason for this assert?

#14 The AssertFatal is warning you of a serious error where all your data isn't being sent.
See how much bitCount + bitNum exceed your maxWriteBitNum. Perhaps you need to make it even larger.

#15 Yeah. It's related to MTU. If your buffer is larger than the MTU, the UDP packet is split into two packets on the wire, and if either get lost, the UDP packet is lost. It's not hugely problematic, but if you're sending a lot of packets that are larger than the MTU (typically 1100-1500 bytes), it could become one.

We also hit the limit with our animation list (TSShapeConstructor). I removed TSShapeConstructor entirely, and instead send a file path in the TSShape (that file is already shipped with the client) as a property.

On the client, we open that file, read the animation paths (one per line) and import them.

#16 I have no idea how to troubleshoot this. I guess I should debug and trace back to which object is causing it. But I am writing a single player game, so can someone tell me how to get rid of this please? Changing the buffer size up to 20,000 doesn't work even. I just want to remove the assert instead.

#17 There's hardcoded limits for UDP packets (somewhere in the platform code, can't remember specifics) set at 1500.

#18 I just want to turn off the assertion so I can debug other things right now. How can I do this?

#19 Ahh... I see - so I just remove the assertion and return here hey? Will this cause problems later?

void BitStream::writeBits(S32 bitCount, const void *bitPtr)
{
   if(!bitCount)
      return;

   if(bitCount + bitNum > maxWriteBitNum)
   {
      //error = true;
      //AssertFatal(false, "Out of range write");
      //return;
   }

#20 With 1.5.2, changing buffer size to 2000 didn't solve the problem. It was ok when running on release mode but just commenting out 'AsssertFatal' clause doesn't work on my side.

One of the above thread of Tim mcClarren describes well about the detail but a bit far from the final solution. :-)

I suffer with this problem randomly whenever I added or changes resource.

Any harmless trick or solutions yet?