I am inclined to believe that GDB is getting called by a signal handler in some code. Another suspect is some system monitoring daemon like 'monit'. When there is a rogue process eating too much memory or CPU, it might be trying to take a backtrace or dump using GDB. On way to troubleshoot is to use 'lsof' on the GDB process and see what files are opened by GDB and see if it gives you any clue. Using 'ps -ef -o cmd,pid,ppid | grep -i gdb', you can figure out how GDB was launched and if it gives you the PID of the attached process, you will know which process is being inspected.
A sledge hammer approach to stub such automatic execution is replacing 'GDB' with a stub 'GDB' which does nothing. Non existence of GDB might signal an error though. I have done such dirty tricks when I had no time to dig deeper into the problem. In the stub GDB, you can log all the command line arguments and the calling process name.
A sample stub in 'C':
#include <stdio.h>
int
main(int argc, char *argv[]) {
size_t sz;
FILE *fp = 0;
fp = fopen("/tmp/gdbstub.log", "a");
if (fp) {
fprintf(fp, "\n%s invoked:", argv[0]);
for (sz = 0; sz < argc - 1; sz++) {
fprintf(fp, "%s ", argv[sz]);
}
fclose(fp);
}
return 0;
}