В 19:32 +0200 на 16.03.2009 (пн), Dan Pascu написа: > The private memory pool used by the internal memory allocator is a 1 MB > area right after the area where static variables are stored. It may be > possible that there is a buffer overflow when writing to some static > variables that gets to write in this pool overwriting the allocator > internal structure. The system memory doesn't have this problem as it is > stored somewhere else. Such a buffer overflow will even go unnoticed by > memory tracing tools as it sees that the write is done in the 1MB that > the program allocated, having no clue that the area is actually managed > by another memory allocator that can get corrupted. >
If a static variable is overwriting the memory buffer, this should be easily visible with valgrind - they're both separate allocations (the pool is a static one too). Now, if there's something that does overflow in the pool, that will go unnoticed by default, but I think there should be some way to make valgrind understand other mallocs (probably via an API to say "i'm an allocator, here's what I did"). > At the same time I do not imply that this is what happens. The way the > memory is corrupted doesn't suggest this pattern as the private memory is > not overwritten from the beginning. It looks more like specific areas are > overwritten as if the memory allocator thinks that the memory area was > released and gives it to someone else on the next call to pkg_malloc, > resulting in 2 different pointers to the area competing for the memory. > Another question is, is there a bug at all, e.g. are there any definitive reports? All the memory corruption problems I've seen can be attributed either to bugs I've introduced or the issues with the non-null terminated BLOBs from Postgres and the zero-length results (again from postgres). -- Regards, Vasil Kolev Attractel NV dCAP #1324, LPIC2 _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
