|
From: Benny C. <bwl...@gm...> - 2005-03-24 18:42:18
|
Jeremy Fitzhardinge <jeremy <at> goop.org> writes: > No, that would print something. I'm guessing recursive allocation, > which likely means a leak. Perhaps it may help if I describe my program a bit. What my program does is to make use of part of the VM area to act as my own heap (the allocation of the 256MB big chunks are for this purpose), so that objects of a particular class C (defined by me) will be stored in that area instead of the traditional heap. C is a class written with type template T, and it serves as a wrapper for objects of type T. Thus, by declaring "C<T> obj;" and calls a member function of C, memory is allocated for the object obj using "T* p = new T;", and then the memory content pointed to by p is copied to my designated area using "memcpy", and finally, a member variable of C is pointed to that piece of designated memory (p is then freed using "delete"). There are 3 big chunks of memory allocated, since I want to make 3 copies for different purposes. The error (SEGV fault without returning to valgrind) happens when I try to create many objects to fill my own "heap" area, and it occurs when nearly all objects (about 16K in total, each 16KB in size) are created and moved to my own "heap". I am trying to reproduce the same error with a simpler program, but not succeeded, instead I find this simple (but use up a lot of virtual memory) program gets another error in valgrind 2.4.0, while running fine in 2.2.0. The program is like this: #include <stdlib.h> #include <stdio.h> int main() { void *v, *t, *c; int i; v = malloc(256 * 1024 * 1024); t = malloc(256 * 1024 * 1024); c = malloc(256 * 1024 * 1024); for (i = 0; i < 64 * 1024 * 1024; i++) { *(int *)((unsigned int)v + i * 4) = 123; *(int *)((unsigned int)t + i * 4) = 456; *(int *)((unsigned int)c + i * 4) = 789; } printf("Ok\n"); return 0; } And the error in 2.4.0 is: valgrind: vg_skiplist.c:418 (vgPlain_SkipList_Insert): Assertion `nn == ((void *)0) || (l->cmp)(key_of_node(l, nn), k) != 0' failed. ==4814== at 0xB003623E: vgPlain_skin_assert_fail (vg_mylibc.c:1170) ==4814== by 0xB003623D: assert_fail (vg_mylibc.c:1166) ==4814== by 0xB0036298: vgPlain_core_assert_fail (vg_mylibc.c:1177) ==4814== by 0xB004452C: vgPlain_SkipList_Insert (vg_skiplist.c:164) ==4814== by 0xB0032DA5: vgPlain_map_file_segment (vg_memory.c:394) ==4814== by 0xB0032F66: vgPlain_map_fd_segment (vg_memory.c:465) ==4814== by 0xB0034F09: vgPlain_mmap (vg_mylibc.c:313) ==4814== by 0xB0036E0A: vgPlain_get_memory_from_mmap (vg_mylibc.c:1705) ==4814== by 0xB0030724: newSuperblock (vg_malloc2.c:479) ==4814== by 0xB00316D4: vgPlain_arena_malloc (vg_malloc2.c:983) ==4814== by 0xB004401C: vgPlain_SkipNode_Alloc (vg_skiplist.c:226) ==4814== by 0xB003270C: vgPlain_split_segment (vg_memory.c:106) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==4814== at 0x804840C: main (trybug.cpp:13) Does valgrind 2.4.0 use up more (virtual) memory than 2.2.0? Best Regards, Benny. |