[Bug]: break_on_failure should use __builtin_debugtrap rather than __builtin_trap
- Dominant language
- C++
- Stars
- 39.5k
- Forks
- 10.9k
- Avg merge
- 6d 13h
- Merged PRs (30d)
- 1
Description
### Describe the issue
`__builtin_trap()` is considered a noreturn function and therefore you are not able to continue debugging after the first failure. Clang has [`__builtin_debugtrap`](https://clang.llvm.org/docs/LanguageExtensions.html#builtin-debugtrap) with the desired semantics. GCC currently [lacks](https://gcc.gnu.org/PR99299) such an extension, but the fallback behavior of `raise(SIGTRAP);` works correctly and is better than `__builtin_trap()`. GCC will need to add such an extension eventually to support C++26's `std::breakpoint()`.
### Steps to reproduce the problem
Run a test with multiple failures with `--gtest_break_on_failure` in gdb. Try to continue. Repeatedly. Note that it stays in the same place because the trap loops.
Now replace `__builtin_trap` with `__builtin_debugtrap` in https://github.com/google/googletest/blob/c67de117379f4d1c889c7581a0a76aa0979c2083/googletest/src/gtest.cc#L5480-L5481
When you try again, you can now continue to the next failure!
### What version of GoogleTest are you using?
```
> git rev-parse HEAD
09ffd0015395354774c059a17d9f5bee36177ff9
```
### What operating system and version are you using?
Linux arm64
### What compiler and version are you using?
```
> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/11/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
```
### What build system are you using?
```
> bazel version
Bazelisk version: development
Build label: 8.3.1
Build target: @@//src/main/java/com/google/devtools/build/lib/bazel:BazelServer
Build time: Mon Jun 30 16:25:49 2025 (1751300749)
Build timestamp: 1751300749
Build timestamp as int: 1751300749
```
### Additional context
_No response_
Contributor guide
Research direction
Start at googletest/src/gtest.cc around lines 5480-5481 and inspect how --gtest_break_on_failure handles compiler-specific trap behavior. Reproduce the issue with a test containing multiple failures under gdb, then verify that continuing reaches the next failure rather than stopping repeatedly at the same trap.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- testing-qa
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 52/100