Is there any way to track down access violations, instead of me having to look through my source code manually.

I have a pretty big source code and an access violation happens at runtime, but it's going to be a nightmare looking through it all to find the access violation. Not to mention all the tests I have to run.

So if there is a way to catch an access violation and find out where it occured it would be appreciated!

On Wednesday, 5 November 2014 at 11:09:42 UTC, Bauss wrote:
> Is there any way to track down access violations, instead of me having to look through my source code manually.
>
> I have a pretty big source code and an access violation happens at runtime, but it's going to be a nightmare looking through it all to find the access violation. Not to mention all the tests I have to run.
>
> So if there is a way to catch an access violation and find out where it occured it would be appreciated!

What OS are you using? Did you run any debugger?

Bauss:

> Is there any way to track down access violations, instead of me having to look through my source code manually.
>
> I have a pretty big source code and an access violation happens at runtime, but it's going to be a nightmare looking through it all to find the access violation. Not to mention all the tests I have to run.
>
> So if there is a way to catch an access violation and find out where it occured it would be appreciated!

This was discussed some times, and Walter is against this, but I think he is wrong, and eventually things will change. So I think this discussion should be brought to the main D newsgroup again.

Ideally in non-release mode D should put asserts where a access violation could happen. But I don't know how much slowdown this will cause. If practical real tests show that the slowdown is excessive, then a compiler switch could be added to activate those asserts.

Bye,
bearophile

On Wednesday, 5 November 2014 at 11:09:42 UTC, Bauss wrote:
> Is there any way to track down access violations, instead of me having to look through my source code manually.
>
> I have a pretty big source code and an access violation happens at runtime, but it's going to be a nightmare looking through it all to find the access violation. Not to mention all the tests I have to run.
>
> So if there is a way to catch an access violation and find out where it occured it would be appreciated!

If you're on Linux, you can turn SEGVs into Errors:

    import etc.linux.memoryerror;
    registerMemoryErrorHandler();

On Wednesday, 5 November 2014 at 11:27:02 UTC, thedeemon wrote:
> On Wednesday, 5 November 2014 at 11:09:42 UTC, Bauss wrote:
>> Is there any way to track down access violations, instead of me having to look through my source code manually.
>>
>> I have a pretty big source code and an access violation happens at runtime, but it's going to be a nightmare looking through it all to find the access violation. Not to mention all the tests I have to run.
>>
>> So if there is a way to catch an access violation and find out where it occured it would be appreciated!
>
> What OS are you using? Did you run any debugger?

I am running Windows, but I am not using any debugger.
I was more looking for a build in function.

On Wednesday, 5 November 2014 at 11:31:01 UTC, bearophile wrote:
> Bauss:
>
>> Is there any way to track down access violations, instead of me having to look through my source code manually.
>>
>> I have a pretty big source code and an access violation happens at runtime, but it's going to be a nightmare looking through it all to find the access violation. Not to mention all the tests I have to run.
>>
>> So if there is a way to catch an access violation and find out where it occured it would be appreciated!
>
> This was discussed some times, and Walter is against this, but I think he is wrong, and eventually things will change. So I think this discussion should be brought to the main D newsgroup again.
>
> Ideally in non-release mode D should put asserts where a access violation could happen. But I don't know how much slowdown this will cause. If practical real tests show that the slowdown is excessive, then a compiler switch could be added to activate those asserts.
>
> Bye,
> bearophile
I agree with you completely thathe is wrong. There should definitely be a way to find access violations within the program. I cannot add asserts and checks everywhere since performance is my number one priority within my program, so I have to make sure that the access violation cannot happen in the first place.
However it's a bit hard to track down access violations in big programs if you don't know when exactly it occured and where exactly it occured.

On Wednesday, 5 November 2014 at 11:39:21 UTC, Marc Schütz wrote:
> On Wednesday, 5 November 2014 at 11:09:42 UTC, Bauss wrote:
>> Is there any way to track down access violations, instead of me having to look through my source code manually.
>>
>> I have a pretty big source code and an access violation happens at runtime, but it's going to be a nightmare looking through it all to find the access violation. Not to mention all the tests I have to run.
>>
>> So if there is a way to catch an access violation and find out where it occured it would be appreciated!
>
> If you're on Linux, you can turn SEGVs into Errors:
>
>     import etc.linux.memoryerror;
>     registerMemoryErrorHandler();

I am on Windows, but thanks that might come in handy when I have to test my program on other platforms.

On Wednesday, 5 November 2014 at 11:31:01 UTC, bearophile wrote:
> This was discussed some times, and Walter is against this, but I think he is wrong, and eventually things will change.

An access violation already thrown on Win32. Just catch a Throwable in main and write out exception.toString. But you do need to have debugging info compiled in to get a readable backtrace with dmd -g.

On Wednesday, 5 November 2014 at 11:39:21 UTC, Marc Schütz wrote:
> If you're on Linux, you can turn SEGVs into Errors:
>
>     import etc.linux.memoryerror;
>     registerMemoryErrorHandler();

Why isn't such a useful feature activated by default? Performance reasons?

On Nov 5, 2014 12:10 PM, "Bauss via Digitalmars-d-learn" < digitalmars-d-learn@puremagic.com> wrote:
>
> Is there any way to track down access violations, instead of me having to
look through my source code manually.

Whenever you don't get a stack trace on Windows, it's 99% guaranteed you're calling a null function pointer.

>
> I have a pretty big source code and an access violation happens at
runtime, but it's going to be a nightmare looking through it all to find the access violation. Not to mention all the tests I have to run.
>
> So if there is a way to catch an access violation and find out where it
occured it would be appreciated!

On Thu, 06 Nov 2014 20:13:02 +0000
"Nordlöw" via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> On Wednesday, 5 November 2014 at 11:39:21 UTC, Marc Schütz wrote:
> > If you're on Linux, you can turn SEGVs into Errors:
> >
> >     import etc.linux.memoryerror;
> >     registerMemoryErrorHandler();
> 
> Why isn't such a useful feature activated by default? Performance reasons?
'cause it's not really that useful. uncaught (by the proper checks) segmentation fault is the serious bug, program must crach and spit out postmortem dump. without interceptions crach point (which is written into the dump too) will be right at the place where it shots it's foot. and with signal handler installed... who knows?

crash+coredump is alot more useful than intercepting error and... trying to recover from undefined state? or just exit to OS, losing valuable information about a crash?