Loading ...
Sorry, an error occurred while loading the content.
 

Re: [tekkotsu_dev] Problem sending data through socket.

Expand Messages
  • Ignacio Herrero Reder
    Thanks for your advices Ethan. The Status Reports - Free Memory Report is a very useful tool indeed. Using it I have seen that my crashing error it is not
    Message 1 of 7 , Apr 1, 2008
      Thanks for your advices Ethan. The "Status Reports" -> "Free Memory
      Report" is a very useful tool indeed. Using it I have seen that my crashing error it is not due to sending data through a socket. Instead, it is due  to an adjusting head function to center the ball to the AIBO's fiel of vision.

      In my Behavior I have defined an extended class of HeadControllerBehavior (e.g. MyHeadControllerBehavior):

      I define in MyClass  a "MyheadControllerBehavior" object to make head movement independent  from the other components:

      MyClass::DoStart(){
       ...
       head=new MyHeadPointControllerBehavior( );
       head->DoStart();
       ...

       }

      and I send head movement commands through corresponding port from JAVA GUI.

      But I want also that AIBO centers its head  to  follow the ball, so I've added an "AutoHead" function:

      void MyHeadPointControllerBehavior::AutoHead(float Cx, float Cy){       
          float pan=state->outputs[HeadOffset+PanOffset]-Cx*M_PI/6;  
          float nod=state->outputs[HeadOffset+NodOffset]-Cy*M_PI/6;  
          if(pan>1.396f)   // 1.396 rad =80º
              pan=1.396f;
          else if(pan<-1.396f)
               pan=-1.396f;
          if(nod>0.698f)   // 0.698 rad =40º
              nod=0.698f;
          else if(nod<-0.2618f) // -0.2618 rad =-15º
              nod=-0.2618f;
          MMAccessor<HeadPointerMC> head(head_id);
          head->setJoints(-0.7f,pan,nod);
      }

      ...which I call from "MyClass"

      as "head->AutoHead(Cx,Cy)" ....where Cx and Cy are the current ball centroid data.

      ...it is strange but this function causes a memory leaking of about 15-20Kb from time to time. Finally the robot crash (I don`t know if it is due to memory leaking or another memory conflict). I know the problem is at the two end sentences for accessing head, (removing them results in no memory leaking and no crashing) but I don't know the reason. Perhaps it is not appropriate to use a (My)HeadControllerBehavior object?
      Best regards, and thanks for your time.
         

      Ignacio Herrero Reder            / Tl. +34-95.213.71.60
      Dpto. Tecnologia Electronica     / Fax: +34-95.213.14.47 
      E.T.S. Ing. Telecomunicacion     / nhr@... 
      Universidad de Malaga            / http://www.dte.uma.es
      Campus Universitario de Teatinos 
      29071 Malaga, Spain  


      Ethan Tira-Thompson escribió:

      > I don't know if it could be a "race condition" problem, a memory
      > problem,....
      The code looks good. I also think it looks like you're running out of
      memory, so there is probably a leak somewhere.

      What version are you using? (2.4 had a memory leak in the vision
      pipeline, so it would run out of memory pretty quickly -- this was
      fixed in 2.4.1, and I'm unaware of a similar bug in later versions...)

      One thing you can use to test is the "Status Reports" -> "Free Memory
      Report"... the numbers will change whenever the Main process needs
      more memory from the system heap, so this is a coarse measurement. .. a
      series of small allocations will eventually show up as a single larger
      decrement in memory. I'm not sure 'frees' actually restore the free
      memory count either (the process seems to hold on to a private pool of
      memory, I don't know the details of Aperios's memory management.. .)

      But anyway, if the Free Memory count is gradually dropping over time,
      it's "just" a matter of figuring out what function(s) correlate with
      the drop...

      A secondary theory is that the memory heap is being corrupted by a
      series of double frees, or freeing from within the middle of an
      allocation, etc. You might want to switch to running with GDB on a
      desktop with logged data to watch for that... (see MALLOC_CHECK_ or
      MallocErrorAbort environment variables to enable additional error
      checking: man malloc)

      -ethan

    • Ignacio Herrero Reder
      Well, I tried a similar pre-compiled Behavior ( Stare at Pink Ball ) and it ALSO has the same memory leaking problem: every 20-30-40 seconds it lost an
      Message 2 of 7 , Apr 1, 2008
        Well, I tried a similar pre-compiled Behavior ("Stare at Pink Ball") and
        it ALSO has the same memory leaking problem: every 20-30-40 seconds it
        lost an INCREASING amount of memory (-23448, - 24960, -26496, -28160...)
        so, at the long term, it crashes.
        I think it could be due to consecutive and too fast calls to "setJoints"
        function, so there are problems to free memory.
        My Behavior probably crashes at an earlier time because of conflicts of
        bad deallocated memory vs new allocating.
        "setJointValue" function behaves the same.

        If I stop the "Stare at Pink Ball" Behavior, lost memory is not
        recovered; if I start it again, it continues losing memory "from the
        quantity" of amount memory it was losing when the behavior was stopped.
        Furthermore, time between memory leaks increases also when the quantity
        of memory leak increases.
        Its strange!! about 40 seconds --> about 40K of memory leak, about 45
        seconds-->about 45K of memory leak;...75 seconds--->75K of memory leak.....


        Ignacio Herrero Reder / Tl. +34-95.213.71.60
        Dpto. Tecnologia Electronica / Fax: +34-95.213.14.47
        E.T.S. Ing. Telecomunicacion / nhr@...
        Universidad de Malaga / http://www.dte.uma.es
        Campus Universitario de Teatinos
        29071 Malaga, Spain
      • Ethan Tira-Thompson
        ... Yeah, I was worried that would be the case... the MMAccessor and setJoints is done many places, so if that triggers the leak, then this would show up many
        Message 3 of 7 , Apr 1, 2008
          > Well, I tried a similar pre-compiled Behavior ("Stare at Pink Ball")
          > and it ALSO has the same memory leaking problem:
          Yeah, I was worried that would be the case... the MMAccessor and
          setJoints is done many places, so if that triggers the leak, then this
          would show up many places (e.g. the head remote control Behaviors/Mon/
          HeadPointControllerBehavior probably does this too, as you move the
          head around...)

          I haven't had a chance to replicate this on my end yet, but I will
          tomorrow.

          My theory is that this is not directly a setJoints() issue, but rather
          an inter-process communication issue. setJoints() (and MMAccessor)
          don't do any memory allocations, but whenever the head pointer (and
          other related such as PostureMC or WalkMC) reach their target, an
          event is generated in the Motion process and sent to the Main
          process. It's quite possible the reference counting is not being done
          correctly and thus these messages are leaking. If you want to
          continue tracking this down, take a look in Events/EventTranslator.h
          (the IPCEventTranslator part)

          Also, to rule out MMAccessor, try doing just the checkout, but just
          don't call any functions on it... hopefully this part is OK.

          Good work so far :)

          -ethan
        • Ignacio Herrero Reder
          Hi Ethan. Memory leaking problem appears also at HeadPoint ControllerBehavior , but only if you move the head too fast, and the memory leaking is less
          Message 4 of 7 , Apr 3, 2008
            Hi Ethan. Memory leaking problem appears also at "HeadPoint ControllerBehavior" , but only if you move the head too fast, and the memory leaking is less frequent than with "Stare at Ball". It appears also when AIBO is shaking its ears for Low Battery warning.  I think the problem is due to too fast allocation-deallocation of memory, as head->setJoints is called  too fast also.

            I did just a checkoutMotion-checkinMotion with no memory leaking. I did also a head->setweightFunction, with no memory leaking. Creating only a MemoryAccessor with no funciton call didn't result in memory leak, too.

            I tried to track the bug at IPCEventTranslator, but those functions are too obscure for me, as I do not know much about the event router system. Furthermore those functions use RegionRC open-R functions whose code is not avalaible (I have not found it!)

            Meanwhile I will avoid to call setJoints when the actual pan,nod is enough close with the desired, so it is called less frequently. I hope this way I could lessen the impact of memory leaking over my Behavior.

            Best Regards.
               

            Ignacio Herrero Reder            / Tl. +34-95.213.71.60
            Dpto. Tecnologia Electronica     / Fax: +34-95.213.14.47 
            E.T.S. Ing. Telecomunicacion     / nhr@... 
            Universidad de Malaga            / http://www.dte.uma.es
            Campus Universitario de Teatinos 
            29071 Malaga, Spain  


            Ethan Tira-Thompson escribió:

            > Well, I tried a similar pre-compiled Behavior ("Stare at Pink Ball")
            > and it ALSO has the same memory leaking problem:
            Yeah, I was worried that would be the case... the MMAccessor and
            setJoints is done many places, so if that triggers the leak, then this
            would show up many places (e.g. the head remote control Behaviors/Mon/
            HeadPointController Behavior probably does this too, as you move the
            head around...)

            I haven't had a chance to replicate this on my end yet, but I will
            tomorrow.

            My theory is that this is not directly a setJoints() issue, but rather
            an inter-process communication issue. setJoints() (and MMAccessor)
            don't do any memory allocations, but whenever the head pointer (and
            other related such as PostureMC or WalkMC) reach their target, an
            event is generated in the Motion process and sent to the Main
            process. It's quite possible the reference counting is not being done
            correctly and thus these messages are leaking. If you want to
            continue tracking this down, take a look in Events/EventTransla tor.h
            (the IPCEventTranslator part)

            Also, to rule out MMAccessor, try doing just the checkout, but just
            don't call any functions on it... hopefully this part is OK.

            Good work so far :)

            -ethan

          • Ethan Tira-Thompson
            ... I doubt the frequency of the allocations would *directly* affect anything. It s simply a matter that when there s a leak, the more often you hit the code
            Message 5 of 7 , Apr 3, 2008
              > I think the problem is due to too fast allocation-deallocation of
              > memory, as head->setJoints is called too fast also.
              I doubt the frequency of the allocations would *directly* affect
              anything. It's simply a matter that when there's a leak, the more
              often you hit the code which leaks, the more you leak.

              > I tried to track the bug at IPCEventTranslator, but those functions
              > are too obscure for me, as I do not know much about the event router
              > system. Furthermore those functions use RegionRC open-R functions
              > whose code is not avalaible (I have not found it!)
              I don't think the leak is internal to the reference counter itself --
              it's that IPCEventTranslator isn't calling RemoveReference when it
              should, either on the sending side or the receiving side. But I can
              track that down.

              In the mean time, to confirm this is the source of the problem, an
              easy test would be to comment out all of the postEvent() calls in
              Motion/HeadPointerMC.* (assuming you're not using those events... or
              at least could do a test without them)

              > Meanwhile I will avoid to call setJoints when the actual pan,nod is
              > enough close with the desired, so it is called less frequently. I
              > hope this way I could lessen the impact of memory leaking over my
              > Behavior.
              yes, that also sounds like a good idea.

              -ethan
            Your message has been successfully submitted and would be delivered to recipients shortly.