| delorie.com/archives/browse.cgi | search |
On Tue, Apr 02, 2002 at 01:33:30PM -0500, Earnie Boyd wrote: >Christopher Faylor wrote: >>>I would get segmentation faults within mallocr.c. The first time it >>>occurred was the originating call was within the code I was adding. I >>>modified the code a bit and that caused the malloc's in environ.cc to >>>issue the segmentation faults in mallocr.c. If you need to know >>>exactly where in mallocr.c that was causing the problem I can most >>>likely reproduce it to get the failure point. >> >>SEGVs are invariably a sign of attempts to free memory that hasn't been >>allocated. > >I wasn't freeing memory I was mallocing memory. Once I've finished my >annual disk cleaning job I'll try to reproduce the problem. Come on. Let's not be literal here. It's a sign of malloc pool corruption. Sometimes this is caused by double freeing of memory prior to a malloc. Sometimes it's caused by overrunning a buffer allocated by malloc. Standard stuff. This sounds suspiciously like the standard cygwin complaint of assuming that a standard function like malloc/free has a basic problem which would cause random SEGVs. To assume such a thing would also require the assumption that thousands of programs out there are inadvertently working around the problem in unknown ways. The alternative is to assume that there is something wrong with *your* program and debug that. I'm aware that adding a MMAP option to malloc may cause the problem not to manifest but that is certainly not a sign that this is fixing the problem rather than working around it. You won't know what the actual problem is until you debug it. cgf
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |