Partial memory leak fix

[jimmy-mcelwain]

A partial fix for #35.

There was a member of the QueueTrajPoint response that was getting initialized twice.

g_messages_QueueTrajPoint.response = motoros2_interfaces__srv__QueueTrajPoint_Response__create();
rosidl_runtime_c__String__init(&g_messages_QueueTrajPoint.response->message);

The response creation call already initialized g_messages_QueueTrajPoint.response->message, so the init call that followed caused a memory leak.

This will not close out the issue, as there is still a trickier memory leak as mentioned in this comment. But from my testing, this does seem to recoup somewhere in the range of 24-48 bytes each connect/disconnect cycle.

[ted-miller]

Are you sure that one line is the only 'relevant' fix? Your other branch had a lot more changes.

I just did 7 disconnects in a row and got these results. It seems to conflict with what you stated during your tests.

Initialization complete. Memory available: (992672) bytes. Memory in use: (55904) bytes
Initialization complete. Memory available: (992632) bytes. Memory in use: (55944) bytes
Initialization complete. Memory available: (992616) bytes. Memory in use: (55960) bytes
Initialization complete. Memory available: (992592) bytes. Memory in use: (55984) bytes
Initialization complete. Memory available: (992560) bytes. Memory in use: (56016) bytes
Initialization complete. Memory available: (992512) bytes. Memory in use: (56064) bytes
Initialization complete. Memory available: (992536) bytes. Memory in use: (56040) bytes

[jimmy-mcelwain]

Ignore the memory available/memory in use printout. That is printed out in the middle of a connect/disconnect cycle. I don't know exactly why it varies (it does on my system too), but I'd guess that it has to do with the still-present memory leak (could be messing with struct byte alignment or something like that). The relevant statistic is the full_connection_cycle delta, which is printed out at the actual end of the connect/disconnect cycle. The other changes that I took out were almost entirely logging statements to nail down the second memory leak.

[ted-miller]

I see. There are two tasks still starting up. So yes, you are correct.

[gavanderhoorn]

could we not move this to a place where initialisation was really complete?

[ted-miller]

Currently, there isn't anywhere to put it where it will give a deterministic value. We will need to add some semaphores to indicate init-complete on each task and wait for those before dropping into the main loop.