-1

I have the following code:

    Data* t = (Data*)(malloc(len_part_ * sizeof(Data)));    
    memcpy(t, data_[i], len_temp_ * sizeof(Data));
    std::swap(t, data_[i]);
    free(t);

The problem is that "A heap has been corrupted" error occruing sometimes in free(t). At these times parameters are:

sizeof(Data) = 8;
len_part_ = 24;
len_temp_ = 8;

Info: data_ field is Data** while Data defined as typedef std::pair<int,int> Data;

VP.
  • 15,509
  • 17
  • 91
  • 161
  • If you removed the swap, you'd achieve the same by calling `free(data_[i])`. Are you sure this call is valid? – Angew is no longer proud of SO Jul 07 '14 at 10:58
  • 2
    And why are you using such C-isms in a C++ program in the first place? – Angew is no longer proud of SO Jul 07 '14 at 10:58
  • The type of `t` is a pointer, so std::swap() is swapping the value of the pointer in t and data[i], not the Data object stored at those addreses. Are you sure that's what you want to do? It seems a little odd to be doing that as the main result will be a very fragmented heap. – Evil Dog Pie Jul 07 '14 at 11:02
  • Are you sure that `len_temp_` is never larger than `len_part_`? You'll corrupt the heap otherwise. – Mike Seymour Jul 07 '14 at 11:04
  • At first, this is not my code, I've just saw it today when tried to launch. Second, `len_temp_` always less than `len_part_` (it was my guess too). I've removed the swap and changed call to `free(data_[i]))` but nothing changed unfortunately. I'd reimplemented everything but I don't have enough time, that's why I've asked about such an odd code and possible solution.. – VP. Jul 07 '14 at 11:23

1 Answers1

0

You can only pass to free precisely what you got back from malloc. Your code doesn't show where data[i] came from, but I'll bet it wasn't malloc.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
  • Well, if data is a pointer to a pointer, all elements could have `malloced` it all in a loop somewhere before, couldn't they? – luk32 Jul 07 '14 at 11:06
  • @luk32 Unlikely, given that he's seeing heap corruption. We can only speculate about parts of the program that we can't see, but the evidence we do have suggests otherwise. – David Schwartz Jul 07 '14 at 11:08
  • IMO, it's a guess not an answer, but it might be right. Still, I feel like it should be a comment. This not the only possibility of getting the heap corrupted. I don't think anyone can properly answer the question in its current state. – luk32 Jul 07 '14 at 11:10
  • @luk32 It's not a guess. It's the most likely explanation. Certainty is almost never possible in human endeavors. – David Schwartz Jul 07 '14 at 11:11
  • Still it's based on a speculation, that could have been clarified. A computer program is a logical construction and it's behaviour is well defined unless it invoked UB. The question can be answered with certainty if all the needed details were given. This is why I am not convinced by your argument, though I understand it. I just don't like unnecessarily speculative answers, in my opinion one should demand a clarification to verify his hypothesis instead of betting. Nonetheless, I am very interested if you got it right =) – luk32 Jul 07 '14 at 11:22
  • @luk32 "Your code doesn't show where data[i] came from, but I'll bet it wasn't malloc." -- That isn't clear enough? – David Schwartz Jul 07 '14 at 11:25