1

I have a function that takes a string and cuts out a some parts of it.

The function does its thing a couple of times until, all of a sudden, the same malloc line that worked fine, crashes with No source available for "0xb7e88a81" error.

Tried to clear out every thing to make sure I'm not sending NULL length or whatever, but still no luck.

It worked at least once (debugged it) but on the second or third iteration it crashes.

char *removeOffsetFromLabel (char *label) {
    char* labelWithoutOffset;
    int i;

    labelWithoutOffset = malloc(strlen(label));
   ........

The crash happens on the malloc line (when trying to move to the next line).

strlen(label) = 7 (checked it)

Any ideas ? I'm using GCC compiler on Eclipse (Ubuntu).

Per FoggyDay's request this is the whole function:

char *removeOffsetFromLabel (char *label) {
char* labelWithoutOffset;
int i;

labelWithoutOffset = (char*)malloc(strlen(label) + 1);
i = 0;
while (label[i] != '\0' && label[i] != OPENING_BRACKET_ASCII_CODE) {
    labelWithoutOffset[i] = label[i];
    i++;
}
labelWithoutOffset[i] = '\0';
return labelWithoutOffset;
}

I do free up "labelWithoutOffset" outside of the function before calling it again.

halfer
  • 19,824
  • 17
  • 99
  • 186
Loves2Develop
  • 774
  • 1
  • 8
  • 29
  • 3
    Try this: `labelWithoutOffset = malloc(strlen(label)+1);`!!!!!!! By allocating one byte too few, you might be corrupting your free store ... and causing some *subsequent* "malloc()" or "free()" to fail. – FoggyDay Mar 17 '14 at 20:34
  • An actual invoke of `malloc()` crashes for very few reasons; heap corruption due to previously invoking undefined behavior being one of them. – WhozCraig Mar 17 '14 at 20:35
  • @FoggyDay, I've added +1, still no go... – Loves2Develop Mar 17 '14 at 20:40
  • When I use malloc I usually specify the variable type before it. And as FoggyDay said, adding one to the length is important. Would be something like: labelWithoutOffset = (char*)malloc(strlen(label)+1); – Inox Mar 17 '14 at 20:40
  • @WhozCraig, I'm not sure I understand what should I do... – Loves2Develop Mar 17 '14 at 20:41
  • @Loves2Develop - You should specify the data type of the malloc pointer by typecasting it as it returns only void pointer on memory allocation. So it should be `labelwithoutoffset = (char)malloc(strlen(label));` – Pranav Jituri Mar 17 '14 at 20:47
  • Actually, something like this: `labelWithoutOffset = (char *)malloc(strlen(label)+1);`. You MUST allocate at least strlen+1 (not just "strnlen()"); if you case, your pointer type is `char *` (not "char"!!!). – FoggyDay Mar 17 '14 at 21:02
  • 1
    ALSO: check for anything that might be overwriting "labelWithoutOffset" *anywhere* in your code. It definitely sounds like you're corrupting/overwriting "malloc'ed" memory. And the nasty thing about that is the *SOURCE* of the corruption could be in a *completely different part of the code* from where you're crashing... [Valgrind](http://cs.ecs.baylor.edu/~donahoo/tools/valgrind/) is a great tool ... but you probably don't have time to learn Valgrind just at the moment :( – FoggyDay Mar 17 '14 at 21:03
  • 1
    @PranavJituri *"You should specify the data type of the malloc pointer by typecasting it as it returns only void pointer on memory allocation"* - Not only is this **not** correct when programming in C ([read here for why](http://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc)), the very example you gave *incorrectly* introduces an error of typecasting `void*` to `char`, guaranteeing in invalid result. **Don't do this.** – WhozCraig Mar 17 '14 at 23:07
  • And along the lines of the comment above, check your `#include` list and ensure you have `#include `. If you don't, and you're compiling on a 64bit system, you're playing with fire. Include it, and do *NOT* cast the result of `malloc()`. If you simply remove the cast and you being receiving a compiler warning telling you something to the effect of "warning implicit declaration of `malloc` returns `int`..." you've likely found your problem (though you still need the +1 on the length). – WhozCraig Mar 17 '14 at 23:11

4 Answers4

3

I wish I could mark all of your answers with V sign to indicate it solved the issue since you've been most helpful.

After digging in I made two changes to my code and things seem to be working fine so far:

  1. Removed two "free" commands that were used on an already freed up pointers (dumb mistake)
  2. Added "pointer = NULL" after every free (just to be on the safe side)

Again, I thank all of you for showing me other issues I had in my code.

StackOverflow ROCKS !

Loves2Develop
  • 774
  • 1
  • 8
  • 29
2

1) As already mentioned above, "malloc()" MUST BE "strlen()+1":

   char *removeOffsetFromLabel (char *label) {
      char* labelWithoutOffset = (char *)malloc(strlen(label)+1);

2) Since this didn't solve the problem, we also need to look at:

a) is "label" valid when we call strlen()?

b) do you have any code that might be overwriting "labelWithoutOffset" somewhere else - after you've allocated it in one call, and before you allocate it again in a different call?

SUGGESTIONS:

a) Add this code (or better, look at "label" in your debugger):

   char *removeOffsetFromLabel (char *label) {
      fprintf (STDERR, "label=%s\n", label);
      fprintf (STDERR, "strlen(label)=%d\n", strlen(label);
      char* labelWithoutOffset = (char *)malloc(strlen(label)+1);

b) Post some more code from "removeOffsetFromLabel()" - maybe we can see where the variable might be "getting stepped on".

PS: If you're feeling ambitious, check out my link to the Valgrind tutorial above it.

But for "quick results", please try suggestions 1) and 2); and let us know how it goes.

FoggyDay
  • 11,962
  • 4
  • 34
  • 48
  • 1) done 2.a) label is valid (and its length is 7, checked that) 2.b) I free that variable outside of the function, a couple of lines after calling the function. I do need it for calling another function with the "Label only" output but then I free it right away. – Loves2Develop Mar 17 '14 at 21:23
  • Bear in mind, moving some mallocs around caused the malloc crash to happen sooner, I felt like malloc num X in my program crashes. and moving the code around caused it to still crash on malloc, but on a different one. – Loves2Develop Mar 17 '14 at 21:26
  • 1
    Well, if you're using multiples mallocs and frees, you should be careful. Check this, might help a little to identify some problem. http://stackoverflow.com/questions/7480655/how-to-troubleshoot-crashes-in-malloc – Inox Mar 17 '14 at 21:39
  • 1
    [**Do NOT cast the result of malloc in C**](http://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc) – WhozCraig Mar 17 '14 at 23:09
1

if strlen(label) is indeed 7, than it's not strlen() but malloc() itself that crashes.

If malloc() crashes, that probably means malloc()'s internal housekeeping was destroyed earlier/elsewhere (by a pointer gone crazy).

Bugs like this are hard (hardest) to find since you can't tell where they are because the crash is likely happening long after the cause.

You might want to look into Valgrind usage.

mfro
  • 3,286
  • 1
  • 19
  • 28
  • I might go with what you offer (valgrind). Trying to install it now on eclipse but this is the point where I know I'm not gonna be able to send it on time (my project). damnnnnn... – Loves2Develop Mar 17 '14 at 21:59
-2

Scratch that.

i dont understand whatever function type that is there, but to my knowledge of malloc(); and strings, since label is an array you should send it like this

void funcCall(int *)
main()
{
    funcCall(label)
}
funcCall(int funcLabel[])
{

}

hope this helps.

Islarf
  • 159
  • 3
  • 11
  • 1
    What's the difference (apart from changing the argument from char* to int*)? Just making it funcCall(char funcLabel[]) instead of funcCall(char* funcLabel)? There is nothing wrong in using char* as argument of the function – Inox Mar 17 '14 at 20:44