Re: [Playerstage-developers] Re: PutCommand Assertion Failed

[Tim A. <ta...@en...>]

Brian,

I think I've discovered the root of my headaches, as it's now resolved.  I noticed at
some point that the symbolic link to my player source directory was targetting
1.4rc2.  This is the link I use in my Makefile for the driver.  I also noticed from
the 1.4 and 1.5 player manuals that the player_position_cmd packet size has increased
from 24 to 26 bytes.  According to my printouts in CDevice::PutCommand() I was trying
to write 26 bytes to a device with device_commandsize 24.

 Just goes to show you how much time and effort can be wasted over a ridiculous
mistake.   Anyway, thanks for all your help Brian.

Tim

Brian Gerkey wrote:

> On Thu, 15 Jul 2004, Tim Arney wrote:
>
> > I have the same constructor preamble as Trogdor, so I can only assume that the
> > buffer is big enough to hold a position command packet.
> >
> > So, just to see if I understand, when a client does something like SetSpeed(),
> > does Player use PutCommand to write the new command to a shared memory space,
> > the size of which is defined in the CDevice call in the driver's constructor
> > preamble?  Then, does the driver read this memory by using GetCommand() is per
> > the Trogdor (and my) driver?
>
> Yep.
>
> > Assuming this is correct, could it be that the driver isn't reading commands as
> > fast as the client is sending them?  Does the command space just get over
> > written, or does it attempt to queue them up?
>
> By default, new commands overwrite old ones, with the buffer being
> big enough to hold just one at a time.  This is the right thing for
> most devices, but not all.  If a driver prefers to queue up commands,
> it's free to do so, by implementing its own PutCommand() that handles
> queueing.  The 'festival' driver, which takes as commands strings to be
> spoken through the speech synthesizer, is an example of this idea.
>
> > Also, just to be sure, is an error like this independent of whether the micro is
> > receiving the commands correctly?
>
> It certainly should be independent....
>
> The problem is that, for some reason, the server thinks that you don't have
> enough room in your buffer to store a command.  That is, the size of the
> incoming command is bigger than the reported size of your command buffer,
> which is CDevice::device_commandsize.
>
> I have two guesses as to what's causing this, and two tips to help you
> diagnose it.
>
> Guess #1: After requesting the correct buffer size in the constructor,
>           you're assigning some smaller value (probably 0)
>           to your CDevice::device_commandsize, which makes the server
>           think that you don't have enough room to hold the command.
>           You might be doing this manually, or by calling SetupBuffers().
>           You should NOT call SetupBuffers() if you've already requested
>           space in your constructor.
>
> Guess #2: There's some heap corruption going on, causing by somebody
>           writing to where they're not supposed to.  In the process,
>           your CDevice::device_commandsize is being overwritten.
>
> Tip #1: Instrument CDevice::PutCommand() in server/device.cc to print out
>         the sizes that are being compared prior to the assertion.
>         Alternatively, you might be able to inspect those values if you
>         run Player under gdb.
>
> Tip #2: Run Player under valgrind, which is a great debugging tool.  It'll
>         tell you anytime that an invalid memory access is made (plus lots
>         of other bugs that you may not have noticed, like reading from
>         uninitialized memory).
>
>                 brian.
>
> p.s. This makes me realize that the length check in PutCommand()
>      should not be an assertion.  If the command won't fit, then the
>      server should just ignore that command, and print an error to
>      console.  I'll fix that.
>
> --
> Brian P. Gerkey                    ge...@ai...
> Stanford AI Lab                    http://ai.stanford.edu/~gerkey