Member Avatar for kararu

HI all, In my c++ program, I did the following.

......
class thr
      {private:
               char *d;
......
        public:
               d =new char[35];
....
}
destructor has the line
delete [ ]d;

i get segmentation error 
 *** glibc detected *** /usr/bin/perl: free(): invalid next size (normal): 0x0000 000001bc7120 ***

But if I do the following in class,no error comes.

char *d;
char id[35];

Here I need not delete since it will automatically get deleted when it comes out of scope.I need this data in object functions.So is it wrong if I do this way?

help me out,pls.

  • 3 Contributors
  • 3 Replies
  • 270 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by kararu

Dani AI

Generated

Short expert note for the thread.

The glibc message "free(): invalid next size" is a classic symptom of heap metadata corruption rather than a direct fault in delete itself. ’s follow-up that a missing NUL after a concatenation caused the crash fits this pattern: C-style string functions scan for '\0', and a missing terminator or an overrun will write past the allocated buffer and corrupt adjacent heap bookkeeping. Two other frequent causes to keep in mind are shallow copies of raw pointers (leading to double-delete) and race conditions if the same buffer is shared between threads.

Practical fixes and safe patterns:

  • Prefer RAII: use std::string instead of manual new/delete. It prevents off-by-one bugs and automatically handles copying and destruction.
#include <string>

struct Thr {
    std::string data;
    void append(const std::string& s) { data += s; }
};
  • If a fixed-size C buffer is required, use size-limited functions that guarantee NUL-termination, e.g. snprintf:
char buf[35];
snprintf(buf, sizeof buf, "%s%s", part1, part2); // truncates safely and NUL-terminates
  • If managing dynamic char*, always allocate len+1, ensure the final '\0' is written, and follow the Rule of Three/Five (or disable copying) to avoid double frees.

Debugging tips:

  • Run under AddressSanitizer (-fsanitize=address) or Valgrind to locate overruns and use-after-free errors.
  • Build with -g and reproduce the crash under gdb to get a backtrace at the failing free() — it often shows where corruption first occurred.
  • When asking for help, include a minimal reproducible example; as and suggested, small, self-contained code makes these problems trivial to pinpoint.

Final note: using a member char[] is fine when sizes and lifetimes are controlled, but dynamic allocation demands careful null-termination and correct copy/destruction semantics.

Recommended Answers

All 3 Replies

Member Avatar for GloriousEremite

Could you post a short program that demonstrates the problem (and that we can actually compile)?

Member Avatar for andor

This is not enoughf information. Post your code.

Member Avatar for kararu

Hi, thanks for your time and interest.Actually it is a c++ program used as inline in my perl program.and so I was not able to attach the full code.sorry.
I found that the string in which I concatenated another string, had no null as last character and so the string was taken to a length till it could find a zero and so when deleted, it gave segmentation error.
thanks again
bubye.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.