Seg fault when calling plan multiple times.

[henrygerardmoore]

I know plan should not be called on the same task multiple times, but we have a behavior that calls plan, and end users of this behavior sometimes call it multiple times in succession.

When they do this, MTC seg faults. I have been trying to make this throw with a readable error message (std::runtime_error("Did you call plan twice in a row?"); or something), but can't figure out a clean way of detecting this. Currently, I'm doing a horrible hack, which is adding

				if ((*current.start()).owner()->size() > 10000) {
					throw std::runtime_error("Did you call plan twice in a row?");
				}

right after line 553 of container.cpp, and that does indeed detect and throw before seg faulting. However, obviously this is a less than ideal means of detection. It works because something is corrupting the Interface ((current.start().owner()) and it ends up thinking that its beginning is at 0x2, which ends up with it of course thinking that it is more than a quintillion elements long 😅 . This ends up seg faulting at line 148 of storage.cpp Thus, this check for an absurd size catches it and throws.

1. This is obviously an ugly fix
2. It might fail if the beginning pointer gets corrupted to a value close to its end, somehow.
3. It throws from a pretty arbitrary spot in the code, and the earlier the throw the better.

Any assistance with where/how this can be better addressed would be appreciated!

[rhaschke]

I know plan should not be called on the same task multiple times

Who states that? Which issues do you observe if you do? I just tested that in MoveIt1 with the pick+place demo and it works just fine.
Please provide a reproducible unit test illustrating your (original) issue.

[rhaschke]

ping @henrygerardmoore

[henrygerardmoore]

Hi Robert, sorry about the long delay. I've been side tracked with other things, I think @pac48 or I will have a minimal example soon. I will close this issue and then when that minimal example is made, we can link it to this. Again, sorry for the delay and the lack of detail in this issue.