EXC_I386_GPFLT is surely referring to “General Protection fault”, which is the x86’s way to tell you that “you did something that you are not allowed to do”. It typically DOESN’T mean that you access out of memory bounds, but it could be that your code is going out of bounds and causing bad code/data to be used in a way that makes for a protection violation of some sort.
Unfortunately it can be hard to figure out exactly what the problem is without more context, there are 27 different causes listed in my AMD64 Programmer’s Manual, Vol 2 from 2005 – by all accounts, it is likely that 8 years later would have added a few more.
If it is a 64-bit system, a plausible scenario is that your code is using a “non-canonical pointer” – meaning that a 64-bit address is formed in such a way that the upper 16 bits of the address aren’t all copies of the top of the lower 48 bits (in other words, the top 16 bits of an address should all be 0 or all 1, based on the bit just below 16 bits). This rule is in place to guarantee that the architecture can “safely expand the number of valid bits in the address range”. This would indicate that the code is either overwriting some pointer data with other stuff, or going out of bounds when reading some pointer value.
Another likely causes is unaligned access with an SSE register – in other word, reading a 16-byte SSE register from an address that isn’t 16-byte aligned.
There are, as I said, many other possible reasons, but most of those involve things that “normal” code wouldn’t be doing in a 32- or 64-bit OS (such as loading segment registers with invalid selector index or writing to MSR’s (model specific registers)).