Addresses from bt in gdb

I am running a server application on a gentoo (3.4.66) machine.

Sometimes the application segfaults nearly directly after start, but when it runs, there doesn't occur any segfault at all. For some reason, this did not happen (yet) in release build, but only occurs during debug build. This is quite confusing, as I usually have to deal with the other way round.

When I start the application from gdb, it looks like this:

Program received signal SIGSEGV, Segmentation fault.
0xb67db7a9 in ?? () from /lib/libc.so.6
(gdb) bt
#0  0xb67db7a9 in ?? () from /lib/libc.so.6
#1  0x00000002 in ?? ()
#2  0x00000001 in ?? ()
#3  0xb68a0158 in ?? () from /lib/libc.so.6
#4  0x00000040 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Sometimes it looks like this:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb1f62b90 (LWP 6624)]
0xb67d81c4 in ?? () from /lib/libc.so.6
(gdb) back
#0  0xb67d81c4 in ?? () from /lib/libc.so.6
#1  0x00000000 in ?? ()

From what I currently know, the corrupt stack and those odd looking adresses (like 0x00000001) seem to be connected together in some kind of stack smashing.

Additional information

I already checked for things related to assert() expressions (like assert(readFile(filename)) does not work in release mode) but could not find any.

Application is built on another system, than it is ran. They have same libs and dependencies as far as I can tell from ldd

Output shown is from a debug build of the application

Can anyone tell me how to solve this, or give hints, where there might be an issue. Maybe there is a way to extract something from the adresses of the stack frames?

Edit: (Updated)
Unfortunately, I only have (release) libc available. The machine does only have local network access and there is no packaging system installed (-bash: emerge: command not found)

I start the app from GDB with this command in my binary folder: LD_LIBRARY_PATH=$PWD/usr/local/lib gdb Server-Linux where "Server-Linux" is a link to the debug executable

Edit2:
thanks to the hint of @n.m. I have valgrind and can run the app with it now. It gives me 142 loss records and:

==15835== LEAK SUMMARY:
==15835==    definitely lost: 544 bytes in 16 blocks.
==15835==    indirectly lost: 8,212 bytes in 2 blocks.
==15835==      possibly lost: 26,192 bytes in 1,062 blocks.
==15835==    still reachable: 141,010 bytes in 800 blocks.
==15835==         suppressed: 0 bytes in 0 blocks.

Also interesting: running it on valgrind (low performance) did not crash yet withing seven tries. I am checking for race conditions and keep the question updated