The rational behind it is simple — how can you check the length of something that does not exist? Also, unlike “managed languages” there is no expectations the run time system will handle invalid data or data structures correctly. (This type of issue is exactly why more “modern” languages are more popular for non-computation or … Read more
Stack overflow is [a] cause, segmentation fault is the result. At least on x86 and ARM, the “stack” is a piece of memory reserved for placing local variables and return addresses of function calls. When the stack is exhausted, the memory outside of the reserved area will be accessed. But the app did not ask … Read more
On most architectures I’ve used, the distinction is that: a SEGV is caused when you access memory you’re not meant to (e.g., outside of your address space). a SIGBUS is caused due to alignment issues with the CPU (e.g., trying to read a long from an address which isn’t a multiple of 4).
Here’s how I was able to find out what the problem was: Click on the issue in the issue navigator (⌘ + 4, then click on the line with the red ! at the start) At the bottom of the file that appears, there should be a line that says something like: 1. While emitting … Read more
Segmentation fault is caused by bad accesses to memory, only if your OS has a MMU (Memory Management Unit). Otherwise, you won’t get it but only strange behavior. The virtual memory (the entire memory accessible to you = 2^(sizeof(pointer_type)*8) (ie: 2^num_bits_in_pointer_type)) is mapped to physical memory in units named pages or segments (paging superseded segmentation … Read more
Author of Botan replied to me that The problem is the globally defined object. The problem is that the mlock pool is a singleton created on first use then destroyed sometime after main returns. First your object is created. It allocates memory. This results in the pool being created. Destruction happens LIFO. So first the … Read more
You’re probably returning an object that’s on the stack. That is, return_Object() probably looks like this: Object& return_Object() { Object object_to_return; // … do stuff … return object_to_return; } If this is what you’re doing, you’re out of luck – object_to_return has gone out of scope and been destructed at the end of return_Object, so … Read more
glewExperimental = GL_TRUE; glewInit(); Should do the magic Experimental Drivers GLEW obtains information on the supported extensions from the graphics driver. Experimental or pre-release drivers, however, might not report every available extension through the standard mechanism, in which case GLEW will report it unsupported. To circumvent this situation, the glewExperimental global switch can be turned … Read more
I don’t know of a gcc option, but you should be able to run the application with gdb and then when it crashes, type where to take a look at the stack when it exited, which should get you close. $ gdb blah (gdb) run (gdb) where Edit for completeness: You should also make sure … Read more
So, unlikely as it may seem, we appear to have hit an actual bona-fide CPU bug. https://web.archive.org/web/20130228081435/http://support.amd.com/us/Processor_TechDocs/41322_10h_Rev_Gd.pdf has erratum #721: 721 Processor May Incorrectly Update Stack Pointer Description Under a highly specific and detailed set of internal timing conditions, the processor may incorrectly update the stack pointer after a long series of push and/or near-call … Read more