- Forum
- General C++ Programming
- Segmentation fault on new??
Segmentation fault on new??
Are there any circumstances when a line like this could cause a segmentation fault?
size is known to be >0. In fact, the debugger tells me this particular time it was 13038.
This seems to happen at random, which would suggest that the actual bug is elsewhere, but it's not like I'm deallocating memory. I'm allocating memory. Not even fence post errors should cause this.
uchar *buffer=new uchar[size];size is known to be >0. In fact, the debugger tells me this particular time it was 13038.
This seems to happen at random, which would suggest that the actual bug is elsewhere, but it's not like I'm deallocating memory. I'm allocating memory. Not even fence post errors should cause this.
Last edited on
Maybe your program is running out of memory allotted to it? If it's not that, I have no clue.
No, that's definitely not it. The error happens early on, at a time when the memory footprint is never more than 40 MB.
It's not impossible, but I have very few static arrays, and the ones I do have, I use to store constants (e.g. a list of operators).
It's the only thing I imagine that could be causing it, given the behavior of the bug, so I guess I'll recheck my bounds.
I can't remember the exact cause the debugger gave me, this time, but I remember a few other times I got a segmentation fault in the same place and function, but at completely different moment, the debugger said it was due to "memory corruption". I'm not really sure what this means. Shouldn't it detect the memory corruption at the moment it happens, rather than when more memory is allocated?
It's the only thing I imagine that could be causing it, given the behavior of the bug, so I guess I'll recheck my bounds.
I can't remember the exact cause the debugger gave me, this time, but I remember a few other times I got a segmentation fault in the same place and function, but at completely different moment, the debugger said it was due to "memory corruption". I'm not really sure what this means. Shouldn't it detect the memory corruption at the moment it happens, rather than when more memory is allocated?
Not if the heap gets corrupted. "Detection" will occur either when a heap block is allocated or freed.
If you are running on Un*x, you could try exporting MALLOC_CHECK_=2 from the shell before running your app. (man malloc for details).
I'd say to make sure you are not free()ing / deleting a block/object more than once or that you aren't accidentally deleting an object that is not on the heap to begin with.
If you are running on Un*x, you could try exporting MALLOC_CHECK_=2 from the shell before running your app. (man malloc for details).
I'd say to make sure you are not free()ing / deleting a block/object more than once or that you aren't accidentally deleting an object that is not on the heap to begin with.
Topic archived. No new replies allowed.