tags:

views:

287

answers:

5

Hi,

I'm writing a program in C++ and for some reason I'm getting a segmentation error at the following line:

char* param= new char[200];

I've tried different variations and even tried putting before it

int* param= new int;//for no reason

and the same error occurs. What might I have done to cause this problem?

What could possibly cause a simple memory allocation like this to give problems.

I would include the rest of the program, but it's over 1000 lines. But feel free to ask for more info.

+8  A: 

Do you do any memory allocating & freeing before this point? If so, you have probably corrupted the heap in some way. Impossible to diagnose further without seeing more code.

anon
Right, especially if, say, there was one of those array allocations earlier, which was freed by, say, scalar delete instead of array delete.
Chris Jester-Young
There are tools you can use to help diagnose this -- electricfence, dlmalloc, valgrind (heavy, but amazing), the HeapValidate call on Windows, Application Verifier on Windows, etc...
leander
I guess I'll try one of the programs you mentioned. I'll let you know how it goes.
Dave
Could you perhaps recommend a good program for checking memory problems etc, for Windows. Something easy to use for a beginner.
Dave
Something already compiled for windows- I just downloaded Duma but have no idea how to compile projects with codeblocks if they don't have a codeblocks project file...
Dave
If you download visual studio express [http://www.microsoft.com/exPress/download/] that will often warn you if you run it in debug mode.
Jon Cage
+1  A: 

I'd say Neil's on the right track - it's probably something you trampled earlier on that's only being caught there.

Have you made sure that:

  1. All previous allocations succeeded.
  2. You've not written past the end or beginnings of any arrays (there's a plethora of information and tools for bounds checking out there).

[Edit] In response to your comment about having 4GB of RAM, suppose you code effectively does the following:

unsigned int amountToAllocate = 0;
amountToAllocate -= 1;

int* someStorage = new int[amountToAllocate];

someStorage[0] = 5;

...because amountToAllocate is an unsigned int, it will wrap round to it's maximum value (4294967295 if unsigned ints are 32 bit on your hardware). So you'd be trying to allocate 4294967295*4 bytes (again, assuming ints are 32 bit for you)... which is ~4*4GB and will fail and die a nasty death.

Jon Cage
Why wouldn't previous allocations have succeeded? I have 4gb Ram!?But seriously, do I need to check for success like in C?
Dave
Yes, you should *always* check to make sure allocations happened if you're going to rely on accessing those later.
Jon Cage
An alternative answer - no, it isn't worth it. I gave up checking for memory allocations when VM became common (over 15 years ago) and have never experienced a single problem due to a failed allocation.
anon
I should probably point out that I mostly work on embedded software running on fairly tightly constrained processing cards which has made me paranoid ;-) ...that said, the issue I posed above would still be a problem since the code probably wasn't intending to try and allocate all that memory.
Jon Cage
+2  A: 

This is how you can use it, I've replaced char with int to store some values in for example but works the same with char.

#include <iostream>

using namespace std;

int main()
{
    int * param = new int[200];

    for (int i = 0; i < 200; ++i) param[i] = i;
    for (int i = 0; i < 200; ++i) cout << param[i] << endl;

    delete[] param;

    return 0;
}
stefanB
Good example although I'd say the problem lies elsewhere so not necessarily all that helpful in finding the source of the OPs problem.
Jon Cage
You're right but since he does not show us any code he can use the example to compare the usage with what he's doing and therefore find the problem himself.
stefanB
+1 : Fair point :-)
Jon Cage
+1  A: 

First, verify that this line is the problem. What happens if you comment it out? (or replace it with char *param = NULL)

Second, the only way this can cause a segfault is if something has already gone wrong previously. What happens before this?

If you can't show us the relevant snippets of code, then that is your problem. Start commenting out bits of code or otherwise isolate potential troublespots. Sooner or later, you'll be able to boil the problem down to a small sample that reproduces the error. At that point, the problem (and solution) may be obvious, and if it isn't, at least you've got a reasonably sized code sample to show us.

jalf
+1 For divide and conquer :-)
Jon Cage
A: 

I second what @jalf is saying. Are you REALLY sure this is the line that is seg faulting? It's very unlikely.

A seg fault happens when you're trying to access memory that you don't have permission to. Since you're not asking for any specific memory but rather letting the "new" memory allocation get it for you, the problem must be elsewhere.

What you should really do is put a bunch of print statements in your code. (I'm assuming you're not comfortable using a debugger?) This will let you see how far the program gets before the seg fault happens. Good luck!

leo grrr
What you should do if you're not comfortable using a debugger is *get comfortable using a debugger* ;)
jalf
lol- I'm using a debugger (codeblocks built in) and it works until that line and then gives a seg fault. There might be certain features of the debugger that I'm not familiar with, but I definitely use it!
Dave