telnetDebugger.cc bugs - and fixes
by Steve Crocker · in Torque Game Engine · 12/22/2001 (2:06 pm) · 2 replies
Hi all,
I ran across a couple of bugs with the telnet debugger that can cause the Tribal IDE script debugger to not connect...
Could also be cause of a scribbler.
First, mCurPos is not initialized in the ctor, so I added
mCurPos = 0;
after line 76
I would prefer initialization lists to assignments in the constructor, but I didn't feel like changing the whole ctor.
Also, in TelnetDebugger::checkDebugRecv
line number 219 is
if(mCurPos == MaxCommandSize) // this shouldn't happen
it should be
if(mCurPos >= MaxCommandSize) // this shouldn't happen
it is trying to check for overflow. It should probably also check to make sure that mCurPos is not negative...
- Enjoy
I ran across a couple of bugs with the telnet debugger that can cause the Tribal IDE script debugger to not connect...
Could also be cause of a scribbler.
First, mCurPos is not initialized in the ctor, so I added
mCurPos = 0;
after line 76
I would prefer initialization lists to assignments in the constructor, but I didn't feel like changing the whole ctor.
Also, in TelnetDebugger::checkDebugRecv
line number 219 is
if(mCurPos == MaxCommandSize) // this shouldn't happen
it should be
if(mCurPos >= MaxCommandSize) // this shouldn't happen
it is trying to check for overflow. It should probably also check to make sure that mCurPos is not negative...
- Enjoy
#2
I think when I was debugging it it looked like LONG_MIN which would have missed the first few tests ( as well as my 'fix' ) and then cause the recv call to read into some random memory.
Glad to hear its already fixed.
12/23/2001 (12:17 pm)
I think the only time mCurPos was out of range was because of when mCurPos was not initialized in the ctor.I think when I was debugging it it looked like LONG_MIN which would have missed the first few tests ( as well as my 'fix' ) and then cause the recv call to read into some random memory.
Glad to hear its already fixed.
Torque Owner Tim Gift
The other == problem doesn't look like a bug to me. Since Net::rec will only read (MaxCommandSize - mCurPos) bytes, mCurPos will never be greater than MaxCommandSize. I don't see any way that mCurPos could go negative either. The code looks fine to me, though it wouldn't hurt to program more defensively.