![]() |
|
#1
|
||||
|
||||
segfault on malloc (C)I've got an issue right now with a very special-case segfault in my code. It only happens on my x86 linux box (as opposed to my PPC one).
my problem is that one of my functions segfaults on this line: Code:
where GCM_FST_ENTRY_LENGTH is 12. how I know what line: Code:
line 135 in GCMextras.c is the above line... it doesn't segfault every time the function is called, but only in a specific case. Any idea about what could be causing it? I've never had something segfault on an malloc before, so I don't even know where to start looking for info (I JUST started learning to use gdb early last week). |
|
#2
|
||||
|
||||
|
Quote:
The problem with segfaults is that even though they occur at one place, they could be a result of something else that you have done in another place. They can be *hell* to track down. What I try to do is trace what I am doing before the failing call. Have I overwritten in another location? Have I free'd a non-valid location? You may want to play with the setting of MALLOC_CHECK_. From the linux man page: Code:
By setting this to 1 or 2, you may be able to find where your memory trashing is actually starting. Hope this helps, d __________________
The best damn Sports Blog period. |
|
#3
|
||||
|
||||
|
well, believe it or not... setting MALLOC_CHECK_=1 (or 2) actually eliminates the bug... So now I'm even more confused...
Also, something I failed to mention earlier, I just realized... when I get the segfault (when MALLOC_CHECK_=0): Code:
when it segfaults, that's the way it goes... I stuck some debugging output after each malloc (alloc'd entry X), which normally could be safely ignored, but it switches where the error happens right before segfaulting... any other suggestions of what I can do to track it down? thanks ...spike Quote:
|
|
#4
|
||||
|
||||
|
Quote:
Hi Spike. That happens to me sometimes to where a MALLOC_CHECK will actually fix a problem due to it making malloc a tad more fault tolerant. IMO, this is not a solution that you want to stick with, because something somewhere is getting trashed. What is strange is all of your free calls shown above. They all claim to be trying to free an invalid pointer. Why is that? Can you post a small code snippet that can be telling enough as to what is happening here? __________________
The best damn Sports Blog period. |
|
#5
|
||||
|
||||
|
Quote:
yeah, I'm not saying that I'm accepting that as being a solution... I found a small memory leak in my code that changed how soon I get the error (after patching that leak, it made this error happen almost immediately rather than after a couple iterations...). I'll post a little code that I think has to do with this error. This is an opensource project hosted on sourceforge, so you can take a look in the CVS if you'd like, if you need to see more. http://gcmtool.sf.net This is the code that I fixed the leak in... I don't think this is the problem: CPP / C++ / C Code:
Here is the function that I'm segfaulting in: CPP / C++ / C Code:
it segfaults on the malloc() line above... and here's one last snippet... this function calls the above function (GCMGetNthFileEntry()): CPP / C++ / C Code:
As you can see, I'm calling a lot of my own functions here... I don't want to post them all, but like I said, check out the CVS from my project page if you want to see anything outside of what's posted here... you can browse it from a web browser, even. =) I've been stepping through my code trying to find any place where I write outside of the bounds of my char*, but I can't seem to find anything. Is there any way of setting a breakpoint in gdb for when something is free()'d? I'd like to know what invalid pointer I'm freeing... Also, I've compared the results of my calculations between x86 and PPC (I'm reading from a file that stores multibyte int values in big-endian, and since this error only happens on little endian (x86), I thought that might be the issue), but everything is exactly the same. I even had it run through a file with 5000 entries and compare them, and they're identical (md5sum of the output). So I'm pretty sure it's not a misplaced ntohl(). Thanks. Last edited by LuciWiz : 25-Mar-2006 at 11:47.
Reason: Please insert your C code between [c] & [/c] tags
|
|
#6
|
||||
|
||||
|
This may be a very dumb comment, but do you have enough room to put in your Null terminator when you only allocate enough for the strlen(source). I always do a +1 to make sure that there is room for the Null character.
CPP / C++ / C Code:
That may just be my paranoia, but it seems like you are possibly placing a character outside of your allocated space. PS - by using c tags instead of code tags, you can get nice syntax highlighting when you post your c/c++ code. See the first sticky thread in this sub-forum for more details. __________________
The best damn Sports Blog period. |
|
#7
|
||||
|
||||
|
Quote:
thanks for the tip about the c tag!!!! oh man... that's sweet... unfortunately I don't need to post any more code... or, fortunately, rather. That strlen()+1 fixed my app. I didn't think that would have any bearing on what was going wrong and it still doesn't really explain why only passing "/opening.bnr" to my GCMGetFileEntryAtPath() function was the only thing that would segfault it, but since that's fixed, now, I'm happy. hopefully, there isn't some other mysterious string that will crash my app, now. The next step is to do a stress test and fetch thousands of files by their absolute paths to see how it handles. Now I just have to make sure I didn't screw up in any more cases. I forgot that strlen doesn't include the \0... Thanks dude... I've got another issue which I'm going to post in another thread tonight if I can't get it resolved. |
|
#8
|
|||
|
|||
|
Excuse me, this question is not about code.
My native language is not English, so I dont know what segfault mens. Is there any synonym. I didn't find that word in my dictionary. Thanks |
|
#9
|
||||
|
||||
|
Quote:
segfault = Segmentation Fault If you work under *nix it is the most common error to get from a badly behaving program. __________________
The best damn Sports Blog period. |
Recent GIDBlog
Python ebook by crystalattice
| Thread Tools | Search this Thread |
| Rate This Thread | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| malloc function | Rosmayati | C Programming Language | 5 | 18-May-2004 21:08 |
| new to C, need an explanation | andre | C Programming Language | 18 | 23-Mar-2004 11:09 |
Network Sites: GIDNetwork · GIDWebHosts · GIDSearch · Learning Journal by J de Silva, The