Summary: | glibc-2.4-r3 - munmap_chunk(): invalid pointer | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Janpieter SOllie <janpieter.sollie> |
Component: | [OLD] Development | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | janpieter.sollie |
Priority: | Normal | ||
Version: | 2006.0 | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
the problem C file
emerge info of the problem system emerge info of the working system header 1 of the .c file 2nd header (on request) the CORRECT problem C file (the other one was bugged) |
Description
Janpieter SOllie
2006-11-05 13:09:15 UTC
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 |