Quote:
Originally Posted by manohar
Iam doing dynamic allocation and freeing properly after using that.
|
So when we try to help you, we should ignore a large area that might contain your bug because you say you're doing that "properly"?
I expect you think each part of your program is doing its job properly. But some part isn't, or you wouldn't have this bug.
Quote:
|
My project is running for 2-3hrs after that iam getting segmentation problem.
|
You should investigate the details of the seg fault with gdb. At minimum get a backtrace to see where in your code the seg fault occurs.
Quote:
|
From the man pages Iam get to know below information on malloc bugs.
|
A lot of people do think optimistic memory allocation is a bug. They're wrong.
Quote:
|
Iam thinking the above scenario is happening for my case. How to know...?
|
That scenario does not fit the symptoms you described. The bug is in your own code.
If you want to be extra certain that supposed "bug" in malloc cannot affect you, you just need to make sure the swap partition on your Linux system is at least a few hundred MB larger than the largest amount of swap your system ever uses. Disk space is cheap so making swap larger than needed should be an insignificant waste of disk space.
Contrast the symptoms you reported in the current thread with what you described in a different recent thread:
http://www.linuxquestions.org/questi...killed-862964/
There isn't enough info there to be sure, but the effects of optimistic allocation are one possibility that might be considered for the symptoms in that thread. If your system has significant extra swap space, then I wouldn't even consider optimistic allocation as a possibility in that thread.
In this thread, even without knowing how much swap space is free, the symptom is wrong for that issue.
Quote:
Originally Posted by manohar
How free knows how much memory need to free.
|
malloc() actually allocates slightly more for each chunk than the amount you request, then it uses a small part at the beginning of what it allocated to store some info to be used later by free(). It passes you a pointer not to the beginning of what was allocated, but to just past the extra it allocated for use by free(). So you get a pointer to a chunk of the size you requested and the extra space it allocated is in the memory immediately before your chunk.
In that extra space, it stores info that lets it deduce the size of the chunk to be freed as well as info to find the next and previous chunks, so that if one or both of those is already free when this chunk gets freed, free() can consolidate small chunks into big chunks.
All the above only applies to ordinary size chunks. Any entirely different system is used for super large chunks. But extra memory is allocated somewhere by malloc() to contain info that free() needs in order to do its job.
Quote:
Originally Posted by manohar
even after free also ptr won't become NULL...?
|
That is correct. If your code expects the ptr to become null when the memory it points to is freed, that is a bug in your code, not a bug in free().
After freeing the memory pointed to by a pointer, your code must not access that memory again. But nothing other than the correctness of your own code actually stops you from accessing that memory. If you do access memory that has already been freed, your code probably won't fail right at the point of that error. If that error causes any symptom at all, it usually is a failure much later in code that seems to be unrelated.
Issue with malloc
