But later on in the code I try to delete stack and I get a segfault. What could cause me to not be able to delete this?

I'm using the debugger and the memory address of stack doesn't change between when I make it and when I delete it.

02-03-2009

cyberfish

You meant

Code:

delete[] stack;

?

That should work.

Are you sure that's where you are getting the segfault? Is that what the debugger backtrace say?

02-03-2009

jcafaro10

Why delete[]? I've never seen that notation before. I've also called delete on other stacks in the program using delete without any problem. The error I'm getting is Segmentation Fault, that's what prints in the console.

Using delete[] vs delete doesn't change the segfault

02-03-2009

Salem

segfaults on delete almost always mean you've trashed the memory pool somewhere with a buffer overrun.

Try valgrind if you're on linux.

02-03-2009

cyberfish

malloc/free
new/delete
new[]/delete[]

don't mix and match them.

From what I heard, Linux doesn't really care, but it is undefined behaviour and there are systems out there that do care (not sure about Windows).

It's unlikely the problem.

I'm assuming you are using Linux.

My guess is you are accessing stack after it has been free'd. Try to compile your code with debugging symbols and run your code through GDB.

Code:

$g++ -g asdf.cpp -o asdf
$gdb asdf
(gdb) run
...
Segmentation Fault
(gdb) backtrace
... it should give you where the crash occured, and the function call stack at that time

Failing that, run your code through Valgrind (a memory error debugger). It's like GDB, but will catch just about every memory error (accessing a block after free'd, double free, memory leak, accessing past the end of allocated blocks, etc).

02-04-2009

Elysia

On Windows, you will get errors if you delete with delete instead of delete[] when you allocate with new[].

02-04-2009

jcafaro10

Thanks for the responses. I am on linux and I allocated using new like so:

Code:

char* stack = new char[STACK_SIZE];

I've traced through with gdb and the segfault occurs right at the delete of the stack. I'll try valgrind. I've never used it but I see it as an option in KDevelop so I'll give it a shot. The weird thing is, I can see the memory that is allocated to the stack when I allocate it, and it doesn't change at all.

02-04-2009

matsp

Yes, most likely it will fault when you delete, but it's also most likely CAUSED by some other piece of code writing to some part of memory that it shouldn't be using.

--
Mats

02-04-2009

Elysia

So to delete it, firstly you must use
delete[] stack;
And if it still does not work, it means you have corrupted memory somewhere.
The easiest way to detect such errors is to use breakpoints that breaks whenever some 4 bytes or so before the allocated address and after the allocated amount is written to.
That should allow you to see the culprit which writes to that area of memory when it should not.
If gdb can do this or how it can is not my area of expertise, however.

02-04-2009

jcafaro10

Hmm.. Any ideas for tracking things that write to specific memory ranges?

02-04-2009

matsp

Quote:

Originally Posted by jcafaro10

Hmm.. Any ideas for tracking things that write to specific memory ranges?

Yes, valgrind is exactly intended for this. But the memory allocation immediately before the stack is the most likely candidate.

--
Mats

02-04-2009

carrotcake1029

Well since you are on linux, try what Salem suggested, use valgrind. Compile your code with the -g flag and run "valgrind --tool=memcheck ./program", and that should get you started. I am to the point now whenever I use malloc or any other derivative function, I always make sure I am doing it right with valgrind.

02-04-2009

Elysia

Oh yes, before that, check if the pointer itself is valid.
Again, use a breakpoint to break when and if the pointer changes.

02-04-2009

jcafaro10

How do I determine if the pointer is valid? GDB+KDevelop tells me the memory address of the pointer. When I allocate the stack the pointer gets a memory address and it keeps that memory address so I don't think that's the problem.

Something that is a little curious is, on my watch list it says stack, and gives me a hex memory address, and under that is *stack and thats got 0x0. I'm not sure what that means though.

02-04-2009

Elysia

Quote:

Originally Posted by jcafaro10

When I allocate the stack the pointer gets a memory address and it keeps that memory address so I don't think that's the problem.

That is what I mean.
Operator new always returns a valid memory address (or throws). So if the pointers value is never changed from the point it is assigned from new, then you can be sure it's valid.
Some debuggers can also check if a pointer points to a valid memory location. But it's best to know if the original value is preserved since this is what you must delete.

Quote:

Something that is a little curious is, on my watch list it says stack, and gives me a hex memory address, and under that is *stack and thats got 0x0. I'm not sure what that means though.