0

I have a problem, that when I try to delete manually allocated pointer, it causes SIGABRT, I can't get to the roots of the cause. The class looks like

class StreamMetadataReader {

protected:
    std::ifstream csvFile;
    std::vector<std::string> header;

public:
    bool openFile(const std::string& path);
};

The object is created manually allocating memory using new operator and stored in a third party library memory:

auto* reader = new StreamMetadataReader;
vxSetNodeAttribute(
  node, VX_NODE_ATTRIBUTE_LOCAL_DATA_PTR, (void *) &reader, sizeof(StreamMetadataReader *)
);

And the pointer address is passed around functions during program execution. I can cast the address to object type and use it properly. At the end of the program, I retrieve the pointer for the last time and call delete operator to free the memory like so:

StreamMetadataReader *reader = nullptr;
vxQueryNode(
    node, VX_NODE_ATTRIBUTE_LOCAL_DATA_PTR, (void *) &reader, sizeof(StreamMetadataReader *)
);
if (reader != nullptr) {
    delete reader;
}

So the debugger says that execution stops when the default destructor tries to free std::vector<std::string> header; object member.

Maybe someone has an idea what is wrong here? I know this is not the best practice solution for this exact problem. Maybe I this could be a use case for some sort of smart pointer (e.g. weak pointer)?

Thanks in advance.

rock-ass
  • 475
  • 5
  • 16
  • 4
    `delete` on `nullptr` is well defined. You don't need to check for it. – François Andrieux Sep 12 '17 at 15:57
  • 1
    Is the address you get the same you created? –  Sep 12 '17 at 15:57
  • I don't know what `VX_NODE_ATTRIBUTE_LOCAL_DATA_PTR` or `vxQueryNode` do, but it looks like it might be writing directly to `&reader`'s memory representation. This is only allowed on [POD](http://en.cppreference.com/w/cpp/concept/PODType) types, which `std::vector` is not. – François Andrieux Sep 12 '17 at 15:58
  • Can you use a tool like Valgrind (Linux) or Application Verifier (Windows) ? This does smell memory corruption (or more simply, the third party lib is writing where it should not) – Synxis Sep 12 '17 at 15:59
  • Related: https://stackoverflow.com/questions/941832/is-it-safe-to-delete-a-void-pointer – Ripi2 Sep 12 '17 at 16:00
  • 1
    More to manni66's question, not only have you verified the same pointer returned, have you also added a destructor and set a breakpoint on it to ensure you're not accidentally deleting the object *twice* ? – WhozCraig Sep 12 '17 at 16:05
  • Thanks everyone for the insights. Yes the address is the same and object deletion is not performed twice, that is for sure. This seems most likely to be the case with POD, the external library is pure C. I will try removing or replacing `std::vector` and see what happens – rock-ass Sep 12 '17 at 18:25

1 Answers1

0

Thanks everyone for your help, I have only recently solved my problem, and that was that I had wrong defines in my project, and that caused my program to be compiled with slightly different headers than the shared library I used. The library I used had precompiler conditions to declare structure members. That caused memory corruption and errors appeared spuriously everywhere.

rock-ass
  • 475
  • 5
  • 16