[fixed]array::erase for multiple non-primitive-type items

[RedDragCZ]

Hello everybody,
I've encountered some really weird behavior with array::erase method when erasing multiple items of non-primitive type.
Let's have for example:

Code: Select all

core::array<core::stringc> aaa;
  aaa.push_back(core::stringc("1"));
  aaa.push_back(core::stringc("2"));
  aaa.push_back(core::stringc("3"));
  aaa.push_back(core::stringc("4"));
  aaa.push_back(core::stringc("5"));

now, calling

Code: Select all

aaa.erase(0, 2);

causes a memory exception (fails to free unallocated memory).

Calling

Code: Select all

aaa.erase(1, 2);

goes fine, but the final array contains elements ("1", "5", "5") instead of expected ("1", "4", "5").
At first, I thought it was some memory-related bug of my arrays, but then I tried and ended up with the exact same results even using the stock Irrlicht 1.7.1.

All the mess seems to be caused by this condition in the erase method:

Code: Select all

if (i > index+count)
				allocator.destruct(&data[i-count]);

which itself doesn't make any sense to me why it is here. Commenting it out, both erase calling variants work as expected.

According to the SVN, this bug seems to be present in all Irrlicht versions (as far as I browsed it).

edit: just grammar correction

[CuteAlien]

Need to check this in detail when I have time in the evening. But on first view I think the line should rather be changed to check for: i > index + 2* count

The idea seems to be not to give free the object which are already destructed before that loop. And 'i' already does add count from the start, so I think it needs 2xcount.

But thanks for reporting!

edit: I really need more time for this - because for now I just don't get the last check for "if (i >= used-count)" - I don't see why it should not destruct otherwise.

[CuteAlien]

Fixed in branches/releases/1.7 in revision 3746. Trunk will follow on next merge.

It was indeed the first check which was wrong, the second one turned out to be ok.

[RedDragCZ]

Thanks!

[CuteAlien]

I'm really surprised why this has never been found before (that bug was in there since years!). I just checked Irrlicht code, seems it was used only in 2 places inside Irrlicht:

- Software rendering might have messed up clipping.
- Collada loader used it in some way

I guess mostly only a single element is erased which has it's own function.

[hybrid]

Hmm, maybe it's then worth trying the sw renderer fixes again. After all, this should have worked, but for some reason the triangles were completely messed up later on...

[CuteAlien]

Yeah, I also thought that at first when I read the comment around that code. But I think it's used in the code which is used as workaround now.