Given the updated screen shot in your most recent edit, it appears there's a bug in an XS module overflowing a buffer, and that's what the stack backtrace is complaining about. You can see in the screen shot the backtrace:
/lib64/libc.so.6(__fortify_fail+0x37)[0x7fb026838637]
/lib64/libc.so.6(+0xf8690)[0x7fb026836690]
/home/ex2-user/j_authority/_Inline/lib/auto/author_da35/author_da35.so(profiles_c+0x27fd)[0x7fb008a529ad]
/home/ex2-user/j_authority/_Inline/lib/auto/author_da35/author_da35.so(XS_author_profiles_c+0x32a)[0x7fb008a55afa]
So, it appears you're in the middle of this XS module when Fortify detected a stack overflow. This suggests a function-local array to some function internal to author_da35
got overrun. This could happen if, for example, it sized some structure expecting 32-bit pointers, but you're running on a 64-bit machine. (Which, it appears you are.) Or, it could just be it allocated a fixed sized structure and your dataset needs something larger.
Looking around, some other classes of problems can trigger "buffer overflow," such as opening too many files, but that seems like a less likely circumstance.
In any case, it appears to be a bug in the module.
If you're not familiar with XS, the short description is that it's a mechanism that allows perl to call native-compiled code. Perl itself is interpreted, but its XS API allows you to interface perl code with compiled languages such as C or C++. A couple links if you're interested in XS:
As far as fixing your problem, you'll need to actually correct the C or C++ code in profiles_c
in author_da35
. Hopefully you're on good terms with the module's author. :-)
You can find out more about Fortify by googling FORTIFY_SOURCE
.