0

I have a block of code that I put in place to check for errors after a function runs. But this block of code is itself causing problems.

ErrorType *error;
CreateObject(..., &error);  // Function argument is ErrorType**
if (error)  // nullptr if no error
{
        log << "Error details here." << std::endl;
        log.close();
        return false;  // Causes application to PROPERLY quit
}

The debugger gives me a "memory access violation, line 3" error quite frequently and half the time, without using a debugger, this code causes a CTD while other times it executes just fine (When running the debugger, I can just hit "Continue" a few times until the block executes as intended.) Do I need to specify something like if (error != nullptr) to get it to work properly? Why is this error-checking block causing errors and how do I fix it?

Note that CreateObject() is an external API function that does not throw any exceptions.

TChapman500
  • 139
  • 13
  • 1
    Are you certain that `if (error)` is actually the line causing the problem? How have you determined this? It's extremely unlikely that it would cause a memory access violation. – François Andrieux May 31 '18 at 14:20
  • Using the Visual Studio debugger (2017). When the error happens, it always breaks on the line with the `if (error)` statement. – TChapman500 May 31 '18 at 14:23
  • 2
    It may be that `CreateObject` is causing the error and VS is breaking on where that call would return to. Try to break on `CreateObject` and stepping over that function call and see if it completes successfully. – François Andrieux May 31 '18 at 14:24
  • I think that CreateObject returns incorrect pointer. I think you need to check the function sources or documentation. It takes pointer to pointer to error type as an argument it looks wired, where actually ErrorType objects are created? I think something is wrong here. – Sandro May 31 '18 at 14:31
  • @Sandro Passing a pointer like that is common to emulate pass-by-reference in C. It might be that `CreateObject` is a C function. – Some programmer dude May 31 '18 at 14:33
  • I just discovered that the function returns an HRESULT. And the debugger isn't cooperating with me. It seems that simply running the debugger reduces the chances of the error. – TChapman500 May 31 '18 at 14:37
  • @Some programmer dude It is common in C to have an integer value as an error code and pass pointer to this value to function. But here we have object of unknown type ErrorType, and probably function should create this object in dynamic memory. I'm not sure that it is really common practice in C. – Sandro May 31 '18 at 14:41
  • @TimothyChapman It seems you need to check returned HRESULT. And I think that if the result is not an error then function does not fill error code. So it points to some incorrect place. – Sandro May 31 '18 at 14:44
  • @Sandro It could be a structure that contains more information about the error, like overall error status, detailed fields, and possible strings with messages? Exactly what `ErrorType` is might be irrelevant to the problem though. – Some programmer dude May 31 '18 at 14:46
  • @Someprogrammerdude Yes, it could be, but where the instance of it should be created? – Sandro May 31 '18 at 14:48
  • 1
    Thanks. But according to the debugger, `error` is `nullptr`, which I thought any `if (ptr)` statements would be skipped if the `ptr` was `nullptr`. Also, the `ErrorType` contains a string that I dump to a file. But I have to use `ErrorType::GetString()` to access it. EDIT: The `ErrorType` object is created by `CreateObject()` if there's an error. – TChapman500 May 31 '18 at 14:49
  • 1
    @TimothyChapman Don't trust debuger. You can try to print the value of error to console after function CreateObject is finished. If error is nullptr then your code is fine, and problem can be somewhere else. – Sandro May 31 '18 at 14:56

0 Answers0