emerge --info: view problem-system source code containing the problem: vieuw attachment dictionary.c I created a library to keep some sort of data in memory. The add() component has the following instructions: INHOUD[index] = calloc(1, sizeof(element)); printf("element %s stored at %x", word1, INHOUD[index]); (storing element word1 and some other not listed char*) INHOUD is a macro subsituted by a pointer to an array of pointers (otherwise it won't be readable), INHOUD[index] is a element* . (element* is a struct) The remove() instruction is as follows: printf("deleting element at %x \n", INHOUD[index]); free(INHOUD[index]); INHOUD[index] = INHOUD[AANTAL -1]; AANTAL--; printf("element freed"); INHOUD = realloc(INHOUD, AANTAL); AANTAL is (again) a macro specifying the number of elements in INHOUD. please take note of the printf() instructions, they 're only here to show the problem. this is the output of the program: element test stored at 502190 element test2 stored at 5021b0 element test stored at 5021d0 element vierendelen stored at 502210 element proberen stored at 502250 deleting element at 5021b0 *** glibc detected *** ./a.out: munmap_chunk(): invalid pointer: 0x00000000005021b0 *** ======= Backtrace: ========= /lib/libc.so.6[0x2b41f5d2141d] ./a.out[0x40096e] ./a.out[0x400da0] /lib/libc.so.6(__libc_start_main+0xf4)[0x2b41f5cd5134] ./a.out[0x400619] ======= Memory map: ======== 00400000-00402000 r-xp 00000000 16:05 827893 /home/janpieter/a.out 00501000-00502000 rw-p 00001000 16:05 827893 /home/janpieter/a.out 00502000-00523000 rw-p 00502000 00:00 0 [heap] 2b41f5b9c000-2b41f5bb7000 r-xp 00000000 16:05 1474623 /lib64/ld-2.4.so 2b41f5bb7000-2b41f5bb9000 rw-p 2b41f5bb7000 00:00 0 2b41f5bda000-2b41f5bdb000 rw-p 2b41f5bda000 00:00 0 2b41f5cb6000-2b41f5cb7000 r--p 0001a000 16:05 1474623 /lib64/ld-2.4.so 2b41f5cb7000-2b41f5cb8000 rw-p 0001b000 16:05 1474623 /lib64/ld-2.4.so 2b41f5cb8000-2b41f5dd9000 r-xp 00000000 16:05 1474159 /lib64/libc-2.4.so 2b41f5dd9000-2b41f5ed9000 ---p 00121000 16:05 1474159 /lib64/libc-2.4.so 2b41f5ed9000-2b41f5edc000 r--p 00121000 16:05 1474159 /lib64/libc-2.4.so 2b41f5edc000-2b41f5ede000 rw-p 00124000 16:05 1474159 /lib64/libc-2.4.so 2b41f5ede000-2b41f5ee4000 rw-p 2b41f5ede000 00:00 0 2b41f5ee4000-2b41f5ef0000 r-xp 00000000 16:05 774766 /lib64/libgcc_s.so.1 2b41f5ef0000-2b41f5ff0000 ---p 0000c000 16:05 774766 /lib64/libgcc_s.so.1 2b41f5ff0000-2b41f5ff1000 rw-p 0000c000 16:05 774766 /lib64/libgcc_s.so.1 7fffb4ef8000-7fffb4f0e000 rw-p 7fffb4ef8000 00:00 0 [stack] ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso] Aborted (core dumped) some people might say it is my own problem, but the program worked fine on this system: (view attachment working_system)
Created attachment 101297 [details] the problem C file
Created attachment 101298 [details] emerge info of the problem system
Created attachment 101299 [details] emerge info of the working system
Created attachment 101300 [details] header 1 of the .c file
Comment on attachment 101300 [details] header 1 of the .c file there's another header file (dictionary_types.h) but it's not worth creating a new attachment for. Here's whats in there: #include <stdlib.h> typedef struct { char* keyword; char* alternative; }element; typedef struct { element** inhoud[26]; int aantal[26]; }dictionary;
i'm not going to debug your code, especially when you havent provided all the files needed to even test it
Created attachment 101317 [details] 2nd header (on request) you 've got eyes to look, please do it printf() prints the CONTENT of the pointer it stores a struct at a specified location, and the location is stored in that pointer when you pass the pointer mentioned to free(), the pointer is invalid. You can see the object is stored at that location, and it's deleted at that location. Besides, if it was MY mistake: -the problem also appears with gcc 3.4.4, AND gcc32, but the old atlon machine with an OTHER glibc doesn't complain. strange, isn't it? -
Created attachment 101318 [details] the CORRECT problem C file (the other one was bugged) I saw I uploaded and old version of the C file, which was indeed corrupt. I'm sorry for that one.
reopened bug - C file was invalid, sorry
no, it isnt strange at all ... your code has buffer overflows and that's your own goddamn problem this isnt a support forum for people writing wrong code, it's a support forum for people with bugs in glibc there is no bug in glibc here but rather glibc is telling you your code is broken; yet you ignore it and care to blame the tools rather than your code if you simply ran your code through a memory debugger you would quickly find the problem ... i'll give you a hint though so you dont come back: element test stored at 0x52cfe0 element test2 stored at 0x52cfa0 dictionary.c:34:Bounds error: attempt to reference memory overrunning the end of an object. dictionary.c:34: Pointer value: 0x0, Size: 16 dictionary.c:34: Object `calloc': dictionary.c:34: Address in memory: 0x0 .. 0xf dictionary.c:34: Size: 16 bytes dictionary.c:34: Element size: 1 bytes dictionary.c:34: Number of elements: 16 dictionary.c:34: Created at: dictionary.c, line 32 dictionary.c:34: Storage class: heap Aborted
I know this is not a forum for helping me to debug my own code. I first asked it on a please-help-me forum, and I din't get any useful responses. I only uploaded because it worked one one PC and not on another ... if you search bugzilla you 'll see there are portage apps having the same problem ... some of them are still marked as 'new' and don't have a solution yet. besides, if I take a look at the post: dictionary.c:34:Bounds error: attempt to reference memory overrunning the end of an object --> what overrunning? I don't refer to memory going out of bounds (at least not IN this object. if it was the object itself, it shoudl crash already at line 33, not 34) ... I will upload a verbose version of ALL actions the program does if you don't believe me. This statement tries to dereference the value stored in the second part of the struct (bytes 8-16) ... If there was any memory overhead, it should not be here, but at dictionary.c:33 (bytes 1-8) ... as the struct object is completely valid (see below) dictionary.c:34: Pointer value: 0x0, Size: 16 --> this is correct, as we have 2 pointers in the struct and we are working with a 64 bit system dictionary.c:34: Object `calloc': dictionary.c:34: Address in memory: 0x0 .. 0xf dictionary.c:34: Size: 16 bytes dictionary.c:34: Element size: 1 bytes -->I needed 1 struct of 16 bytes, not 16 bytes apart dictionary.c:34: Number of elements: 16 dictionary.c:34: Created at: dictionary.c, line 32 --> = (element*) calloc( 1, sizeof(element)); --> seems clear dictionary.c:34: Storage class: heap about the memory debugger: I did so, step by step, analyzing every goddamn value referenced in the registers of the CPU... (using gdb and making a memory dump for each step) and still I couldn't find anything wich wasn't right. that's why I thought it was the glibc: if the memory is out of bounds, then the 'reservations' where not stored properly. I did some debugging before I did this post, believe me. I have a version where every time malloc(), calloc(), realloc() or free() are called, ALL POSSIBLE useful elements are printed ... but NOTHING was even close to a bug. if there is a bug, then it's the program that maps the memory ... glibc or the linux kernel. Regardless if it's a glibc bug or not, you guys don't seem to be interested, so I'll try to find a solution myself
the reason other bugs are open in bugzilla is because those are packages that are in portage and have maintainers ... the code in question here is yours as for the notion it should have crashed earlier, that just shows you should do some reading about how memory allocation is done in linux ... memory is allocated in page sizes which means that small overruns are typically not caught unless you use an actual memory debugger
