Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 8890189
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: June 14, 20262026-06-14T22:26:37+00:00 2026-06-14T22:26:37+00:00

I was fighting with this problem for 2 days. I have a workaround but

  • 0

I was fighting with this problem for 2 days. I have a workaround but I want to understand what happens more. So let’s begin.
I have very Primitive exception class that holds an error message as a pointer to array of chars (I know about profit of std::string). I know the “rule of three” so it looks like:

globalexceptions.hpp

class FatalError {
    public:
        const char* errorMessage;
        /* WARNING:
         * "Rule of three". You see it below.
         */
        FatalError(const char* pErrorMessage);
        FatalError(const FatalError& rhs);
        FatalError& operator=(const FatalError& rhs);
        ~FatalError();
};

globalexceptions.cpp

FatalError::FatalError(const char *pErrorMessage):
    errorMessage(pErrorMessage)
{}

FatalError::FatalError(const FatalError& rhs){
    char* buf = new char[strlen(rhs.errorMessage)+1];
    strcpy(buf, rhs.errorMessage);
    errorMessage = buf;
}

FatalError& FatalError::operator =(const FatalError& rhs){
    if (this == &rhs)
        return *this;
    delete[] errorMessage;
    char* buf = new char[strlen(rhs.errorMessage)+1];
    strcpy(buf,rhs.errorMessage);
    errorMessage = buf;
    return *this;
}

FatalError::~FatalError(){
    delete[] errorMessage;
}

But when throwing:

int Config::readConfig(int argc_p, char *argv_p[])
{
    if ( argc_p != 2 )
    {
        throw FatalError ("Sick usage. Try: <file.ini>\n");
    }

I get “SIGABRT”.

Some valgrind analysis:

Invalid free() / delete / delete[] / realloc()
  in FatalError::~FatalError() in globalexceptions.cpp:26
Address 0x413980 is not stack'd, malloc'd or (recently) free'd  1: operator delete[](void*) in /tmp/buildd/valgrind-3.7.0/coregrind/m_replacemalloc/vg_replace_malloc.c:490
  2: FatalError::~FatalError() in <a href="file:///home/gumba/Projects/cpp/backup_helper/backup_helper-build-desktop-Qt_4_8_2_in_PATH__System__Debug/../backup_helper/globalexceptions.cpp:26" >globalexceptions.cpp:26</a>
  3: /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17
  4: main in <a href="file:///home/gumba/Projects/cpp/backup_helper/backup_helper-build-desktop-Qt_4_8_2_in_PATH__System__Debug/../backup_helper/main.cpp:35" >main.cpp:35</a>

I’ve done some research, and found the following information and advices:

  • (OK: Catch by reference) “Technically, even when you catch an exception by reference, the compiler still uses pass by value. This is due to the fact that a catch never returns control to the caller, and is thus responsible for clean-up”
  • (OK: Have copy constructor) “Objects that are thrown must have a publicly accessible copy-constructor. The compiler is allowed to generate code that copies the thrown object any number of times, including zero. However even if the compiler never actually copies the thrown object, it must make sure the exception class’s copy constructor exists and is accessible”

According to GDB the copy constructor is not called. SIGABRT happens on delete[] errorMessage. I don’t understand why. errorMessage seems to be properly initialized.

What is the reason of SIGABRT?

Thanks!

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-06-14T22:26:38+00:00Added an answer on June 14, 2026 at 10:26 pm

    The problem is here:

    FatalError::FatalError(const char *pErrorMessage):
        errorMessage(pErrorMessage)
    {}
    

    You shouldn’t just store that const char*, you should allocate enough size in your errorMessage member, and copy it there. Otherwise, in the destructor, you’ll be deleteing the address of the string literal, which will lead to undefined behaviour.

    Anyway, you shouldn’t use pointers here. Just use std::string, which handles memory for you:

    class FatalError {
    public:
        FatalError(const char *msg) : errorMessage(msg) {}
        // Add an overload for std::strings
        FatalError(const std::string &msg) : errorMessage(msg) {}
    
        std::string errorMessage;
    };
    

    No need to implement copy assignment operator, copy constructor, nor destructor.

    A better solution would be to use std::runtime_error, which is exactly the same as you implemented, and it’s provided in the standard library:

    #include <stdexcept>
    
    int Config::readConfig(int argc_p, char *argv_p[])
    {
        if ( argc_p != 2 )
        {
            throw std::runtime_error("Sick usage. Try: <file.ini>\n");
        }
        // ....
    }
    
    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

I have been fighting with this upload problem for a couple of days and
I have been fighting this problem with the help of a RegEx cheat sheet,
I've been fighting this crazy problem for hours and have gotten nowhere. I have
i feel dumb for asking this but i have been fighting with this for
I have been fighting this issue for days now and about to beat my
For the last 2 hours I have been fighting with this problem and trying
I have been fighting with this for days now. I have created my own
I'm fighting with this database and i have a strange problem... If I try
We are fighting this problem: We have a big table in SQL Server 2008
I've been fighting this problem for many hours now and could really use some

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.