Restore "Check failure stack trace" message on LOG(FATAL) #1110
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1110 +/- ##
==========================================
+ Coverage 63.57% 63.65% +0.07%
==========================================
Files 20 20
Lines 2578 2578
Branches 894 907 +13
==========================================
+ Hits 1639 1641 +2
Misses 671 671
+ Partials 268 266 -2
|
sergiud
requested changes
Jun 22, 2024
| // We really want [[noreturn]] on the destructor so the compiler can use it. | ||
| // We really just want to reuse the parent class's destructor since it has all | ||
| // the right logic in it. | ||
| LogMessage::~LogMessage(); |
There was a problem hiding this comment.
The destructors in a class hierarchy are generally called in the reverse order of construction. Explicitly invoking the base class destructor means that the base class destructor will be called a second time. However, at that point the object no longer exists. I suspect this is UB territory.
google#1074 refactored some of the code to enable the failure function to throw. This made it so when the LogMessageFatal class was used, the error ended up being printed differently. Before: LOG_AT_LEVEL(google::LogSeverity::FATAL) << "Crash: Hello world!"; -> F20240621 18:12:44.710584 139620827212672 log_demo.cc:16] Crash: Hello world! *** Check failure stack trace: *** @ 0x559e2704711a @ 0x7efc01fac24a @ 0x7efc01fac305 @ 0x559e27046dd5 Aborted LOG(FATAL) << "Crash: Hello world!"; -> F20240621 18:13:05.760556 140518290856832 log_demo.cc:16] Crash: Hello world! @ 0x55cdc2475130 @ 0x7fccf6fb324a @ 0x7fccf6fb3305 @ 0x55cdc2474df5 Aborted With this patch, they both produce the same output. Signed-off-by: Austin Schuh <austin.linux@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
#1074 refactored some of the code to enable the failure function to throw. This made it so when the LogMessageFatal class was used, the error ended up being printed differently.
Before:
LOG_AT_LEVEL(google::LogSeverity::FATAL) << "Crash: Hello world!"; ->
F20240621 18:12:44.710584 139620827212672 log_demo.cc:16] Crash: Hello world!
*** Check failure stack trace: ***
@ 0x559e2704711a
@ 0x7efc01fac24a
@ 0x7efc01fac305
@ 0x559e27046dd5
Aborted
LOG(FATAL) << "Crash: Hello world!"; ->
F20240621 18:13:05.760556 140518290856832 log_demo.cc:16] Crash: Hello world!
@ 0x55cdc2475130
@ 0x7fccf6fb324a
@ 0x7fccf6fb3305
@ 0x55cdc2474df5
Aborted
With this patch, they both produce the same output.