3

I wonder if anyone might have any insight on this...

My program is crashing on this call:

void subtract(data* array,data* inverse,int a, int b, int q, int n)
{

data* arraytomultiply;
arraytomultiply = (data *)malloc(sizeof(data*) * n);

Where data just holds an int (it's for convenience when switching types later)

typedef struct { 
        int value;
}data;

I've tried lots of messing around with changing the pointers here as I'm not confident on them at all, but to no avail.

The strange thing is, much earlier in the program this same call works, I assign values to it and can print them out and everything..:

data* array;
array = (data*)malloc(sizeof(data*) * m * n); // m * n entries

One thing that might be of use (though I have no idea why) is that when it works earlier it's during a void function, whereas when it crashes it's in a function called from within an algorithm. but I don't see how this could affect it at all, given what I'm trying to do isn't using any of the arguments etc...

Any ideas?

quetzal
  • 31
  • 3
  • 1
    When `malloc` crashes, it's almost always the result of memory being corrupted earlier. I'm betting that data was written immediately before or after a block of data that was `malloc`ed earlier. – Drew Dormann Jan 06 '12 at 17:23
  • Ah, maybe that's it so, I'll go back over earlier mallocs and check them, thanks :) – quetzal Jan 06 '12 at 17:26
  • Do you have a core file for the crash? If you do, and you paste the backtrace, it would help diagnose the problem. – dbeer Jan 06 '12 at 17:27
  • You might want to check the value of n in the call to subtract. Check it against a reasonable limit. Other than memory corruption, I've seen this fail when the number of bytes allocated was some very large value because of some uninitialized variable. Since n is passed in from the function call, it is good programming practice to check its value. – Lou Jan 06 '12 at 17:29
  • dbeer, how would I go about finding that? I usually use GDB for debugging but I've recently had to switch to windows with VS 2010 - this is my first program with it! Lou: thanks but n is set by the user at the start and carries through the program.. – quetzal Jan 06 '12 at 17:37
  • this tip probably wont fix the crash, but I believe you should always check the return value of *malloc()*. Can you post more code in order to try to help you? – Cacho Santa Jan 06 '12 at 17:57
  • If you run the program in gdb until it crashes, and then type bt full you'll get the full backtrace – dbeer Jan 06 '12 at 19:05

4 Answers4

5

Shouldn't that be sizeof(data) instead of sizeof(data*) since you're allocating space for data structures?

Joachim Isaksson
  • 176,943
  • 25
  • 281
  • 294
  • Thanks, I just tried that again though and it's still the same crash. Maybe my malloc is trying to allocate space that's already in use or something? – quetzal Jan 06 '12 at 17:17
  • 1
    If it's the actual malloc() call crashing as you say in the title, you've most likely overwritten parts of the heap, either by allocating too little memory somewhere, or by using memory that has already been free'd. I'd look at the latest use of malloc()'d memory before the crashing malloc(). – Joachim Isaksson Jan 06 '12 at 17:56
  • Thanks, I think that's the best approach, I'm going through it now! – quetzal Jan 07 '12 at 17:12
  • Thanks for the Joachim; it turned out to be elsewhere, I simply put in too large a number in a for loop, so it was trying to put in integers where there was no memory allocated I guess, which led to the crash later. It turned out to be so silly, but this has been a good learning experience, and good to know I was allocating too much memory anyway! – quetzal Jan 08 '12 at 03:24
1

You are allocating m * n elements of data * and not data. If you want array of pointers to data then what you are doing in malloc() is correct but that should be assigned to data **

array = (data*)malloc(sizeof(data*) * m * n); // m * n entries

It should be

array = (data*)malloc(sizeof(data) * m * n); // m * n entries

and, you should always check the return value of malloc() to find whether it fails or succeeds! 

if ((array = (data*)malloc(sizeof(data) * m * n)) == NULL) {
    printf("unable to allocate memory");
    return; // you can return your error code here!
}

Your program has all the reason to crash. But when you said, it worked earlier but crashed later made be to do some experiments. I tried your code snippet and found it working for me. I tried many a times but it never crashed. I got puzzled and I posted a question to find out why?! - It is available here Are "malloc(sizeof(struct a *))" and "malloc(sizeof(struct a))" the same?

+1 to your question!

Community
  • 1
  • 1
Sangeeth Saravanaraj
  • 16,027
  • 21
  • 69
  • 98
0

You all are right, but anyhow I wonder why this crashes.

I wonder because the size of data (as defined above) is expected to be less or equal to the size of data*.

alk
  • 69,737
  • 10
  • 105
  • 255
  • Yeah, that's what I was thinking, I could see why it would go wrong the other way around, but why would it crash allocating more space than is needed.. – quetzal Jan 06 '12 at 17:20
0

When malloc crashes, it is usually because you have messed up the structures it uses to track memory on the heap somewhere else. Is your program multi-threaded? Try running it with helgrind or drd (both valgrind tools). These can help you track down race conditions, unprotected data accesses, or other threading issues.

dbeer
  • 6,963
  • 3
  • 31
  • 47
  • Hi dbeer, my program isn't multithreaded up as far as that point, it comes multithreaded when I transfer this new array over to the GPU for calculations, but in this version it hasn't created it. Strangely enough the whole thing worked fine in 2d, but I'm trying to flatten my arrays as it's easier to move them to the GPU then.. – quetzal Jan 06 '12 at 17:47