Redirect c++ crash to stderr











up vote
3
down vote

favorite












Considering a small program like this :



int main()
{
freopen("./stdout.log", "w", stdout);
freopen("./stderr.log", "w", stderr);

int a = 1 / 0;
}


and considering my program is ran by a third party software where I can't change neither how the program is launched nor the environment.



How to properly catch the Floating point exception (core dumped) message issued by the division by zero and any other messages that would still be printed on the tty ?



I've tried to search SO for similar answer but I might be just typing the wrong keywords as it seems a common practice.










share|improve this question


















  • 7




    You need to catch the signals, which is platform dependent.
    – Matthieu Brucher
    Nov 9 at 15:16










  • Have you get a look to std::terminate_handler ?
    – Gojita
    Nov 9 at 15:28






  • 1




    @Gojita Despite its name Floating point exception is a signal (SIGFPE), not an std::exception
    – Mike Kinghan
    Nov 9 at 15:41










  • That's operating system dependant. You need to specify the operating system your third party is running that program on.
    – Luis Colorado
    Nov 15 at 9:58















up vote
3
down vote

favorite












Considering a small program like this :



int main()
{
freopen("./stdout.log", "w", stdout);
freopen("./stderr.log", "w", stderr);

int a = 1 / 0;
}


and considering my program is ran by a third party software where I can't change neither how the program is launched nor the environment.



How to properly catch the Floating point exception (core dumped) message issued by the division by zero and any other messages that would still be printed on the tty ?



I've tried to search SO for similar answer but I might be just typing the wrong keywords as it seems a common practice.










share|improve this question


















  • 7




    You need to catch the signals, which is platform dependent.
    – Matthieu Brucher
    Nov 9 at 15:16










  • Have you get a look to std::terminate_handler ?
    – Gojita
    Nov 9 at 15:28






  • 1




    @Gojita Despite its name Floating point exception is a signal (SIGFPE), not an std::exception
    – Mike Kinghan
    Nov 9 at 15:41










  • That's operating system dependant. You need to specify the operating system your third party is running that program on.
    – Luis Colorado
    Nov 15 at 9:58













up vote
3
down vote

favorite









up vote
3
down vote

favorite











Considering a small program like this :



int main()
{
freopen("./stdout.log", "w", stdout);
freopen("./stderr.log", "w", stderr);

int a = 1 / 0;
}


and considering my program is ran by a third party software where I can't change neither how the program is launched nor the environment.



How to properly catch the Floating point exception (core dumped) message issued by the division by zero and any other messages that would still be printed on the tty ?



I've tried to search SO for similar answer but I might be just typing the wrong keywords as it seems a common practice.










share|improve this question













Considering a small program like this :



int main()
{
freopen("./stdout.log", "w", stdout);
freopen("./stderr.log", "w", stderr);

int a = 1 / 0;
}


and considering my program is ran by a third party software where I can't change neither how the program is launched nor the environment.



How to properly catch the Floating point exception (core dumped) message issued by the division by zero and any other messages that would still be printed on the tty ?



I've tried to search SO for similar answer but I might be just typing the wrong keywords as it seems a common practice.







c++






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 9 at 15:12









Masadow

460212




460212








  • 7




    You need to catch the signals, which is platform dependent.
    – Matthieu Brucher
    Nov 9 at 15:16










  • Have you get a look to std::terminate_handler ?
    – Gojita
    Nov 9 at 15:28






  • 1




    @Gojita Despite its name Floating point exception is a signal (SIGFPE), not an std::exception
    – Mike Kinghan
    Nov 9 at 15:41










  • That's operating system dependant. You need to specify the operating system your third party is running that program on.
    – Luis Colorado
    Nov 15 at 9:58














  • 7




    You need to catch the signals, which is platform dependent.
    – Matthieu Brucher
    Nov 9 at 15:16










  • Have you get a look to std::terminate_handler ?
    – Gojita
    Nov 9 at 15:28






  • 1




    @Gojita Despite its name Floating point exception is a signal (SIGFPE), not an std::exception
    – Mike Kinghan
    Nov 9 at 15:41










  • That's operating system dependant. You need to specify the operating system your third party is running that program on.
    – Luis Colorado
    Nov 15 at 9:58








7




7




You need to catch the signals, which is platform dependent.
– Matthieu Brucher
Nov 9 at 15:16




You need to catch the signals, which is platform dependent.
– Matthieu Brucher
Nov 9 at 15:16












Have you get a look to std::terminate_handler ?
– Gojita
Nov 9 at 15:28




Have you get a look to std::terminate_handler ?
– Gojita
Nov 9 at 15:28




1




1




@Gojita Despite its name Floating point exception is a signal (SIGFPE), not an std::exception
– Mike Kinghan
Nov 9 at 15:41




@Gojita Despite its name Floating point exception is a signal (SIGFPE), not an std::exception
– Mike Kinghan
Nov 9 at 15:41












That's operating system dependant. You need to specify the operating system your third party is running that program on.
– Luis Colorado
Nov 15 at 9:58




That's operating system dependant. You need to specify the operating system your third party is running that program on.
– Luis Colorado
Nov 15 at 9:58












1 Answer
1






active

oldest

votes

















up vote
2
down vote



accepted










Matthieu Brucher's comment is correct:




You need to catch the signals, which is platform dependent.




From the text of the message, I infer that you may be running on a Linux platform. If so, you can catch the SIGFPE signal.



#include <stdexcept>
#include <signal.h>

// compile with -fnon-call-exceptions (for gcc)
signal(SIGFPE, (int signum) { throw std::logic_error("FPE"); });


The linked answer has some C++ niceties such as using a std::shared_ptr for RAII management of the signal handler and mentions compiler flags needed for gcc to make that work.



The Linux Programming Interface book also has a pure-C example.





In Windows, you can use Structured Exception Handling (SEH) and the concept is similar (although the functions you need to call are not).





Note that in either case you're relying on platform-specific behavior not specified by C++ (division by zero is undefined behavior) so obviously this will not result in portable code.






share|improve this answer























  • Super bad idea. Throwing std::exception from from signal handler is a recipe for a mighty disaster
    – SergeyA
    Nov 9 at 15:43










  • @SergeyA I agree and edited the answer. That part came from the linked answer, and I left it alone assuming they knew something I didn't.
    – TypeIA
    Nov 9 at 15:44










  • @SergeyA Actually, I am reverting the edit, as it seems my original thought (that they knew something I didn't) was accurate: gcc with -fnon-call-exceptions does allow this to work. The documentation specifically mentions SIGFPE as a use case.
    – TypeIA
    Nov 9 at 15:48












  • Than you need to add this information to the answer, and be super-specific about compiler. Alternatively, since your answer doesn't add much to the other answer you linked, you can delete your answer and close this question as a duplicate. As it stands, your answer is a (bastardized to the point of being incorrect) copy.
    – SergeyA
    Nov 9 at 16:47










  • @Sergey I do mention the necessary gcc flag in the answer, and I don't see how it is "wrong" in any way. I augmented the other answer with information about other platforms, in a way that won't fit in a comment. I will leave the answer as-is; if mods wish to delete it or close, that's fine. I appreciate your input but please be respectful.
    – TypeIA
    Nov 9 at 16:56











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














 

draft saved


draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53228369%2fredirect-c-crash-to-stderr%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
2
down vote



accepted










Matthieu Brucher's comment is correct:




You need to catch the signals, which is platform dependent.




From the text of the message, I infer that you may be running on a Linux platform. If so, you can catch the SIGFPE signal.



#include <stdexcept>
#include <signal.h>

// compile with -fnon-call-exceptions (for gcc)
signal(SIGFPE, (int signum) { throw std::logic_error("FPE"); });


The linked answer has some C++ niceties such as using a std::shared_ptr for RAII management of the signal handler and mentions compiler flags needed for gcc to make that work.



The Linux Programming Interface book also has a pure-C example.





In Windows, you can use Structured Exception Handling (SEH) and the concept is similar (although the functions you need to call are not).





Note that in either case you're relying on platform-specific behavior not specified by C++ (division by zero is undefined behavior) so obviously this will not result in portable code.






share|improve this answer























  • Super bad idea. Throwing std::exception from from signal handler is a recipe for a mighty disaster
    – SergeyA
    Nov 9 at 15:43










  • @SergeyA I agree and edited the answer. That part came from the linked answer, and I left it alone assuming they knew something I didn't.
    – TypeIA
    Nov 9 at 15:44










  • @SergeyA Actually, I am reverting the edit, as it seems my original thought (that they knew something I didn't) was accurate: gcc with -fnon-call-exceptions does allow this to work. The documentation specifically mentions SIGFPE as a use case.
    – TypeIA
    Nov 9 at 15:48












  • Than you need to add this information to the answer, and be super-specific about compiler. Alternatively, since your answer doesn't add much to the other answer you linked, you can delete your answer and close this question as a duplicate. As it stands, your answer is a (bastardized to the point of being incorrect) copy.
    – SergeyA
    Nov 9 at 16:47










  • @Sergey I do mention the necessary gcc flag in the answer, and I don't see how it is "wrong" in any way. I augmented the other answer with information about other platforms, in a way that won't fit in a comment. I will leave the answer as-is; if mods wish to delete it or close, that's fine. I appreciate your input but please be respectful.
    – TypeIA
    Nov 9 at 16:56















up vote
2
down vote



accepted










Matthieu Brucher's comment is correct:




You need to catch the signals, which is platform dependent.




From the text of the message, I infer that you may be running on a Linux platform. If so, you can catch the SIGFPE signal.



#include <stdexcept>
#include <signal.h>

// compile with -fnon-call-exceptions (for gcc)
signal(SIGFPE, (int signum) { throw std::logic_error("FPE"); });


The linked answer has some C++ niceties such as using a std::shared_ptr for RAII management of the signal handler and mentions compiler flags needed for gcc to make that work.



The Linux Programming Interface book also has a pure-C example.





In Windows, you can use Structured Exception Handling (SEH) and the concept is similar (although the functions you need to call are not).





Note that in either case you're relying on platform-specific behavior not specified by C++ (division by zero is undefined behavior) so obviously this will not result in portable code.






share|improve this answer























  • Super bad idea. Throwing std::exception from from signal handler is a recipe for a mighty disaster
    – SergeyA
    Nov 9 at 15:43










  • @SergeyA I agree and edited the answer. That part came from the linked answer, and I left it alone assuming they knew something I didn't.
    – TypeIA
    Nov 9 at 15:44










  • @SergeyA Actually, I am reverting the edit, as it seems my original thought (that they knew something I didn't) was accurate: gcc with -fnon-call-exceptions does allow this to work. The documentation specifically mentions SIGFPE as a use case.
    – TypeIA
    Nov 9 at 15:48












  • Than you need to add this information to the answer, and be super-specific about compiler. Alternatively, since your answer doesn't add much to the other answer you linked, you can delete your answer and close this question as a duplicate. As it stands, your answer is a (bastardized to the point of being incorrect) copy.
    – SergeyA
    Nov 9 at 16:47










  • @Sergey I do mention the necessary gcc flag in the answer, and I don't see how it is "wrong" in any way. I augmented the other answer with information about other platforms, in a way that won't fit in a comment. I will leave the answer as-is; if mods wish to delete it or close, that's fine. I appreciate your input but please be respectful.
    – TypeIA
    Nov 9 at 16:56













up vote
2
down vote



accepted







up vote
2
down vote



accepted






Matthieu Brucher's comment is correct:




You need to catch the signals, which is platform dependent.




From the text of the message, I infer that you may be running on a Linux platform. If so, you can catch the SIGFPE signal.



#include <stdexcept>
#include <signal.h>

// compile with -fnon-call-exceptions (for gcc)
signal(SIGFPE, (int signum) { throw std::logic_error("FPE"); });


The linked answer has some C++ niceties such as using a std::shared_ptr for RAII management of the signal handler and mentions compiler flags needed for gcc to make that work.



The Linux Programming Interface book also has a pure-C example.





In Windows, you can use Structured Exception Handling (SEH) and the concept is similar (although the functions you need to call are not).





Note that in either case you're relying on platform-specific behavior not specified by C++ (division by zero is undefined behavior) so obviously this will not result in portable code.






share|improve this answer














Matthieu Brucher's comment is correct:




You need to catch the signals, which is platform dependent.




From the text of the message, I infer that you may be running on a Linux platform. If so, you can catch the SIGFPE signal.



#include <stdexcept>
#include <signal.h>

// compile with -fnon-call-exceptions (for gcc)
signal(SIGFPE, (int signum) { throw std::logic_error("FPE"); });


The linked answer has some C++ niceties such as using a std::shared_ptr for RAII management of the signal handler and mentions compiler flags needed for gcc to make that work.



The Linux Programming Interface book also has a pure-C example.





In Windows, you can use Structured Exception Handling (SEH) and the concept is similar (although the functions you need to call are not).





Note that in either case you're relying on platform-specific behavior not specified by C++ (division by zero is undefined behavior) so obviously this will not result in portable code.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 9 at 15:48

























answered Nov 9 at 15:33









TypeIA

13.1k2241




13.1k2241












  • Super bad idea. Throwing std::exception from from signal handler is a recipe for a mighty disaster
    – SergeyA
    Nov 9 at 15:43










  • @SergeyA I agree and edited the answer. That part came from the linked answer, and I left it alone assuming they knew something I didn't.
    – TypeIA
    Nov 9 at 15:44










  • @SergeyA Actually, I am reverting the edit, as it seems my original thought (that they knew something I didn't) was accurate: gcc with -fnon-call-exceptions does allow this to work. The documentation specifically mentions SIGFPE as a use case.
    – TypeIA
    Nov 9 at 15:48












  • Than you need to add this information to the answer, and be super-specific about compiler. Alternatively, since your answer doesn't add much to the other answer you linked, you can delete your answer and close this question as a duplicate. As it stands, your answer is a (bastardized to the point of being incorrect) copy.
    – SergeyA
    Nov 9 at 16:47










  • @Sergey I do mention the necessary gcc flag in the answer, and I don't see how it is "wrong" in any way. I augmented the other answer with information about other platforms, in a way that won't fit in a comment. I will leave the answer as-is; if mods wish to delete it or close, that's fine. I appreciate your input but please be respectful.
    – TypeIA
    Nov 9 at 16:56


















  • Super bad idea. Throwing std::exception from from signal handler is a recipe for a mighty disaster
    – SergeyA
    Nov 9 at 15:43










  • @SergeyA I agree and edited the answer. That part came from the linked answer, and I left it alone assuming they knew something I didn't.
    – TypeIA
    Nov 9 at 15:44










  • @SergeyA Actually, I am reverting the edit, as it seems my original thought (that they knew something I didn't) was accurate: gcc with -fnon-call-exceptions does allow this to work. The documentation specifically mentions SIGFPE as a use case.
    – TypeIA
    Nov 9 at 15:48












  • Than you need to add this information to the answer, and be super-specific about compiler. Alternatively, since your answer doesn't add much to the other answer you linked, you can delete your answer and close this question as a duplicate. As it stands, your answer is a (bastardized to the point of being incorrect) copy.
    – SergeyA
    Nov 9 at 16:47










  • @Sergey I do mention the necessary gcc flag in the answer, and I don't see how it is "wrong" in any way. I augmented the other answer with information about other platforms, in a way that won't fit in a comment. I will leave the answer as-is; if mods wish to delete it or close, that's fine. I appreciate your input but please be respectful.
    – TypeIA
    Nov 9 at 16:56
















Super bad idea. Throwing std::exception from from signal handler is a recipe for a mighty disaster
– SergeyA
Nov 9 at 15:43




Super bad idea. Throwing std::exception from from signal handler is a recipe for a mighty disaster
– SergeyA
Nov 9 at 15:43












@SergeyA I agree and edited the answer. That part came from the linked answer, and I left it alone assuming they knew something I didn't.
– TypeIA
Nov 9 at 15:44




@SergeyA I agree and edited the answer. That part came from the linked answer, and I left it alone assuming they knew something I didn't.
– TypeIA
Nov 9 at 15:44












@SergeyA Actually, I am reverting the edit, as it seems my original thought (that they knew something I didn't) was accurate: gcc with -fnon-call-exceptions does allow this to work. The documentation specifically mentions SIGFPE as a use case.
– TypeIA
Nov 9 at 15:48






@SergeyA Actually, I am reverting the edit, as it seems my original thought (that they knew something I didn't) was accurate: gcc with -fnon-call-exceptions does allow this to work. The documentation specifically mentions SIGFPE as a use case.
– TypeIA
Nov 9 at 15:48














Than you need to add this information to the answer, and be super-specific about compiler. Alternatively, since your answer doesn't add much to the other answer you linked, you can delete your answer and close this question as a duplicate. As it stands, your answer is a (bastardized to the point of being incorrect) copy.
– SergeyA
Nov 9 at 16:47




Than you need to add this information to the answer, and be super-specific about compiler. Alternatively, since your answer doesn't add much to the other answer you linked, you can delete your answer and close this question as a duplicate. As it stands, your answer is a (bastardized to the point of being incorrect) copy.
– SergeyA
Nov 9 at 16:47












@Sergey I do mention the necessary gcc flag in the answer, and I don't see how it is "wrong" in any way. I augmented the other answer with information about other platforms, in a way that won't fit in a comment. I will leave the answer as-is; if mods wish to delete it or close, that's fine. I appreciate your input but please be respectful.
– TypeIA
Nov 9 at 16:56




@Sergey I do mention the necessary gcc flag in the answer, and I don't see how it is "wrong" in any way. I augmented the other answer with information about other platforms, in a way that won't fit in a comment. I will leave the answer as-is; if mods wish to delete it or close, that's fine. I appreciate your input but please be respectful.
– TypeIA
Nov 9 at 16:56


















 

draft saved


draft discarded



















































 


draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53228369%2fredirect-c-crash-to-stderr%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Schultheiß

Liste der Kulturdenkmale in Wilsdruff

Android Play Services Check