Linux coredump backtrace missing frames

I got a core dump from a multi-threaded process segmentation fault crash. While inspecting the core file using GDB, I found some threads (not all) having such backtrace:

Thread 4 (LWP 3344):
#0  0x405ced04 in select () from /lib/arm-linux-gnueabi/libc.so.6
#1  0x405cecf8 in select () from /lib/arm-linux-gnueabi/libc.so.6
#2  0x000007d0 in ?? ()
#3  0x000007d0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

I check in our source code and found those threads do eventually call select(). I'd like to understand why/how those middle frames are omitted.

Such pattern also occurs to read() call.

Any idea what is going on here? I'm afraid that this indicates something wrong with our coredump configuration, or something. Thank you in advance for the help!!

Edit: Thanks for all responses. I apologize I didn't give enough info. Here are more: The executable is built with compiler -g and without any optimizations, using -O0. We generally only used less than half of our RAM 300-400 MB/1G.
Actually, I also saw this pattern backtrace in different core files (dumped for different faults). What makes this symptom really wired (differ from ordinary stack corrupt) is that more than one threads have such back trace pattern, with frame #0, #1 exactly the same as this one, but #2 #3 addresses may differ from this.

It looks like you might be compiling without debugging enabled.

Make sure you pass in -g when compiling.

Also, as Joachim Pileborg mentioned in his comment, the repeated stack frame implies that you probably corrupted your stack somewhere. That is usually the result of writing past the end of an array, into the stored frame pointer.