Re: Access Violation Tracking
On 11/11/14 10:14 AM, Kagamin wrote: On Friday, 7 November 2014 at 03:45:23 UTC, Steven Schveighoffer wrote: In an environment that you don't control, the default behavior is likely to print "Segmentation Fault" and exit. No core dump, no nothing. If you let the exception propagate into OS, by default Windows creates memory dump. Windows is a different story. You actually get a reasonable result. On Unix flavors, you get a signal, and by default, an exit, with the following message: Segmentation fault prompt> No history, no core dump (generally this is off by default), no information as to where it occurred, why it occurred. Nothing. -Steve
Re: Access Violation Tracking
On Saturday, 8 November 2014 at 15:51:59 UTC, Gary Willoughby wrote: This is really cool, (and at the risk of sounding foolish) what is the benefit of doing this? It turns segfault into normal exception with a stack trace, so you see where it failed right away.
Re: Access Violation Tracking
On Friday, 7 November 2014 at 03:45:23 UTC, Steven Schveighoffer wrote: In an environment that you don't control, the default behavior is likely to print "Segmentation Fault" and exit. No core dump, no nothing. If you let the exception propagate into OS, by default Windows creates memory dump.
Re: Access Violation Tracking
On Mon, 10 Nov 2014 11:13:11 + via Digitalmars-d-learn wrote: > On Sunday, 9 November 2014 at 14:45:11 UTC, ketmar via > Digitalmars-d-learn wrote: > > On Sun, 09 Nov 2014 09:33:29 -0500 > > Etienne via Digitalmars-d-learn > > > > wrote: > > > >> I've seen a lot more invalid memory operation errors since the > >> GC calls destructors. Letting the GC destroy objects out of > >> order can be the issue. We might have to make an associative > >> array of static global flags (debug bool[void*]) for each > >> object to see if it was destroyed, and use asserts in the > >> destructors / update the associative array, as a new idiom. > > that's where i want precise GC to come into play. i really want > > it to > > nullify all internal pointers to finalized objects before > > calling > > destructor. sure, this can modify alot of members, so it must > > be opt-in > > feature. > > > > ah, and stop calling class finalizers "destructors" helps too. > > they > > are... well... finalizers, not destructors. ;-) > > I once suggested to introduce dedicated finalizers that get > called instead of the destructor by the GC, and nobody argued > against it ;-) > > They would be applicable to both classes and structs. A finalizer > may only perform a subset of what's allowed in destructors, and > the compiler might be able to verify that. For DRYness, the > finalizer can optionally be called by the destructor, because > everything that is valid in a finalizer should also be valid in a > destructor. by the way, constructors are essentially initializers, 'cause they called with already constructed objects. and not only constructed, but even initialized with default values. i was always disappointed by the fact that i can't change the way object *constructed* in *constructor*. signature.asc Description: PGP signature
Re: Access Violation Tracking
On Sunday, 9 November 2014 at 14:45:11 UTC, ketmar via Digitalmars-d-learn wrote: On Sun, 09 Nov 2014 09:33:29 -0500 Etienne via Digitalmars-d-learn wrote: I've seen a lot more invalid memory operation errors since the GC calls destructors. Letting the GC destroy objects out of order can be the issue. We might have to make an associative array of static global flags (debug bool[void*]) for each object to see if it was destroyed, and use asserts in the destructors / update the associative array, as a new idiom. that's where i want precise GC to come into play. i really want it to nullify all internal pointers to finalized objects before calling destructor. sure, this can modify alot of members, so it must be opt-in feature. ah, and stop calling class finalizers "destructors" helps too. they are... well... finalizers, not destructors. ;-) I once suggested to introduce dedicated finalizers that get called instead of the destructor by the GC, and nobody argued against it ;-) They would be applicable to both classes and structs. A finalizer may only perform a subset of what's allowed in destructors, and the compiler might be able to verify that. For DRYness, the finalizer can optionally be called by the destructor, because everything that is valid in a finalizer should also be valid in a destructor.
Re: Access Violation Tracking
On Sun, 09 Nov 2014 09:33:29 -0500 Etienne via Digitalmars-d-learn wrote: > I've seen a lot more invalid memory operation errors since the GC calls > destructors. Letting the GC destroy objects out of order can be the > issue. We might have to make an associative array of static global flags > (debug bool[void*]) for each object to see if it was destroyed, and use > asserts in the destructors / update the associative array, as a new idiom. that's where i want precise GC to come into play. i really want it to nullify all internal pointers to finalized objects before calling destructor. sure, this can modify alot of members, so it must be opt-in feature. ah, and stop calling class finalizers "destructors" helps too. they are... well... finalizers, not destructors. ;-) signature.asc Description: PGP signature
Re: Access Violation Tracking
On 2014-11-05 6:09 AM, 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! I've seen a lot more invalid memory operation errors since the GC calls destructors. Letting the GC destroy objects out of order can be the issue. We might have to make an associative array of static global flags (debug bool[void*]) for each object to see if it was destroyed, and use asserts in the destructors / update the associative array, as a new idiom.
Re: Access Violation Tracking
On Sat, 08 Nov 2014 15:51:58 + Gary Willoughby via Digitalmars-d-learn 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(); > > This is really cool, (and at the risk of sounding foolish) what > is the benefit of doing this? adding a little more undefined behavior to your program. UB is always nice! ;-) signature.asc Description: PGP signature
Re: Access Violation Tracking
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(); This is really cool, (and at the risk of sounding foolish) what is the benefit of doing this?
Re: Access Violation Tracking
On Sat, 08 Nov 2014 11:46:16 + Nikolay via Digitalmars-d-learn wrote: > > i also developed a habit of writing assert()s before > > dereferencing > > pointers first time (including class refs) in appropriate > > places, so > > i'll got that stack trace for free. ;-) and i never turning off > > that > > asserts in "release builds". > > If we can't rely on system level may be we should have internal > check for null deref like for array bounds? my memory can cheat me, but i bet that this was discussed before and Walter is against it. signature.asc Description: PGP signature
Re: Access Violation Tracking
i also developed a habit of writing assert()s before dereferencing pointers first time (including class refs) in appropriate places, so i'll got that stack trace for free. ;-) and i never turning off that asserts in "release builds". If we can't rely on system level may be we should have internal check for null deref like for array bounds?
Re: Access Violation Tracking
On Fri, 7 Nov 2014 22:58:38 -0800 "H. S. Teoh via Digitalmars-d-learn" wrote: > Some time ago deadalnix gave a neat (if scary) hack where the signal > handler overwrites its return address on the stack to redirect the code > to a handler that operates outside signal handler context, so it has no > restrictions on syscalls that it can use. it's implementation detail which is free to change. as i said, such code relies on implementation details and "defined undefined behavior". there is no guarantees that you will get the same stack for signal handler and for application. sure, we can do some tricks that exploiting black magic knowledge, but that's what i surely don't want to see in normal code. besides, segfault can be raised inside libc, for example. passing bad argument to some fXXX() operation and BOOM! at this point libc can hold some locks, has some internal state variables initialized and some not, and so on. so no malloc(), no FILE* i/o, no formatted printing, etc. only bare syscalls. and replacing return address will not help in this case. signature.asc Description: PGP signature
Re: Access Violation Tracking
On Sat, Nov 08, 2014 at 08:50:20AM +0200, ketmar via Digitalmars-d-learn wrote: > On Fri, 07 Nov 2014 13:52:33 + > "Nordlöw" via Digitalmars-d-learn > wrote: > > > On Friday, 7 November 2014 at 03:22:59 UTC, ketmar via > > Digitalmars-d-learn wrote: > > > 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? > > > > Together with the DUB package backtrace this gives really nice > ...undefined behavior. this code is not only unsafe (even in perverted > D "safety"), it's plainly wrong. you are not allowed to call most of > the libc functions from signal handler. actually, the things you can > do safely in signal handler is setting some variable or calling > _exit(2). ok, there are some more syscalls which are safe, but > obviously not FILE* i/o from libc. > > so it doesn't matter wether i want coredumps or you want stack traces, > the only correct solution is coredumps. printing stack trace from > signal handler is UB, and it works only by accident. there is no good > in using code that relies on UB. Some time ago deadalnix gave a neat (if scary) hack where the signal handler overwrites its return address on the stack to redirect the code to a handler that operates outside signal handler context, so it has no restrictions on syscalls that it can use. Since by the time control passes to that handler, the "official" signal handler has returned, you can do whatever you want without running into UB. (Of course, overwriting return addresses on the stack arguably qualifies as UB, but hey, when a man is desperate...) T -- "Real programmers can write assembly code in any language. :-)" -- Larry Wall
Re: Access Violation Tracking
On Sat, 08 Nov 2014 06:23:39 + Nikolay via Digitalmars-d-learn wrote: > I think, it is problem. Dland on windows gives stacktrace without > any problem. In general it is expected behavior for many people > from different languages (Java, C#). So from my point of view it > is bad idea has core dump for null deref in linux by default. this is the only choice. invoking file i/o from signal handler is UB. signature.asc Description: PGP signature
Re: Access Violation Tracking
On Fri, 07 Nov 2014 13:52:33 + "Nordlöw" via Digitalmars-d-learn wrote: > On Friday, 7 November 2014 at 03:22:59 UTC, ketmar via > Digitalmars-d-learn wrote: > > 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? > > Together with the DUB package backtrace this gives really nice ...undefined behavior. this code is not only unsafe (even in perverted D "safety"), it's plainly wrong. you are not allowed to call most of the libc functions from signal handler. actually, the things you can do safely in signal handler is setting some variable or calling _exit(2). ok, there are some more syscalls which are safe, but obviously not FILE* i/o from libc. so it doesn't matter wether i want coredumps or you want stack traces, the only correct solution is coredumps. printing stack trace from signal handler is UB, and it works only by accident. there is no good in using code that relies on UB. signature.asc Description: PGP signature
Re: Access Violation Tracking
i also developed a habit of writing assert()s before dereferencing pointers first time (including class refs) in appropriate places, so i'll got that stack trace for free. ;-) and i never turning off that asserts in "release builds". About null pointer deref & core dump I think, it is problem. Dland on windows gives stacktrace without any problem. In general it is expected behavior for many people from different languages (Java, C#). So from my point of view it is bad idea has core dump for null deref in linux by default. As I remember current linux handler is dirty hack, and it is main reason why it is disabled by default.
Re: Access Violation Tracking
On Fri, 07 Nov 2014 13:52:33 + "Nordlöw" via Digitalmars-d-learn wrote: > On Friday, 7 November 2014 at 03:22:59 UTC, ketmar via > Digitalmars-d-learn wrote: > > 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? > > Together with the DUB package backtrace this gives really nice > default behaviour printing stacktrace where memory fault occurred. > > For details see my show case at: > https://github.com/nordlow/justd/blob/master/t_errorHandler.d but i don't want stacktrace! i want coredump, so i can inspect the program, it's variables and it's internal state. i want to know *how* *exactly* program manages to shot itself in the foot. easily catchable segfaults are not surviving testing. and if segfault survives, most of the time it's not enough to get stack trace, i need to fire gdb with coredump and try to understand what the hell is going on there. i also developed a habit of writing assert()s before dereferencing pointers first time (including class refs) in appropriate places, so i'll got that stack trace for free. ;-) and i never turning off that asserts in "release builds". signature.asc Description: PGP signature
Re: Access Violation Tracking
On Fri, 07 Nov 2014 08:49:34 -0500 Steven Schveighoffer via Digitalmars-d-learn wrote: > On 11/6/14 11:43 PM, ketmar via Digitalmars-d-learn wrote: > > On Thu, 06 Nov 2014 22:45:23 -0500 > > Steven Schveighoffer via Digitalmars-d-learn > > wrote: > > > >> In an environment that you don't control, the default behavior is likely > >> to print "Segmentation Fault" and exit. No core dump, no nothing. > >> > >> This leads to unhelpful bug reports, and seeing if you can get your > >> client to "try to make it happen again with this debug build, or with > >> the shell set up to make a core dump". > > > > README file, prerequisites: "please, turn on coredump feature if you > > plan to send bug reports. thank you." > > This doesn't help. We must live in the real world with real customers :) i do. this really helps when clients wants their problem to be solved. and if they doesn't, it's sufficient to answer like "thank you for your report, we are working on it" (and then dumping that "report" to /dev/null). this works perfectly. signature.asc Description: PGP signature
Re: Access Violation Tracking
On Friday, 7 November 2014 at 03:22:59 UTC, ketmar via Digitalmars-d-learn wrote: 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? Together with the DUB package backtrace this gives really nice default behaviour printing stacktrace where memory fault occurred. For details see my show case at: https://github.com/nordlow/justd/blob/master/t_errorHandler.d
Re: Access Violation Tracking
On 11/6/14 11:43 PM, ketmar via Digitalmars-d-learn wrote: On Thu, 06 Nov 2014 22:45:23 -0500 Steven Schveighoffer via Digitalmars-d-learn wrote: In an environment that you don't control, the default behavior is likely to print "Segmentation Fault" and exit. No core dump, no nothing. This leads to unhelpful bug reports, and seeing if you can get your client to "try to make it happen again with this debug build, or with the shell set up to make a core dump". README file, prerequisites: "please, turn on coredump feature if you plan to send bug reports. thank you." This doesn't help. We must live in the real world with real customers :) -Steve
Re: Access Violation Tracking
On Thu, 06 Nov 2014 22:45:23 -0500 Steven Schveighoffer via Digitalmars-d-learn wrote: > In an environment that you don't control, the default behavior is likely > to print "Segmentation Fault" and exit. No core dump, no nothing. > > This leads to unhelpful bug reports, and seeing if you can get your > client to "try to make it happen again with this debug build, or with > the shell set up to make a core dump". README file, prerequisites: "please, turn on coredump feature if you plan to send bug reports. thank you." btw, that's why i'm against so-called "release builds" with debug features not only turned off, but not compiled at all. every build must be "release build", and no debug features should be ommited. when i stopped to making "debug builds" and started to pass my clients the same builds i'm using as developer, things becomes much easier. signature.asc Description: PGP signature
Re: Access Violation Tracking
On 11/6/14 10:22 PM, ketmar via Digitalmars-d-learn wrote: On Thu, 06 Nov 2014 20:13:02 + "Nordlöw" via Digitalmars-d-learn 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 In an environment that you don't control, the default behavior is likely to print "Segmentation Fault" and exit. No core dump, no nothing. This leads to unhelpful bug reports, and seeing if you can get your client to "try to make it happen again with this debug build, or with the shell set up to make a core dump". I think it would be nice to be able to check if a core dump is enabled, and if not, register the handler by default. -Steve
Re: Access Violation Tracking
On Thu, 06 Nov 2014 20:13:02 + "Nordlöw" via Digitalmars-d-learn 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? signature.asc Description: PGP signature
Re: Access Violation Tracking
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!
Re: Access Violation Tracking
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?
Re: Access Violation Tracking
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.
Re: Access Violation Tracking
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.
Re: Access Violation Tracking
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.
Re: Access Violation Tracking
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();
Re: Access Violation Tracking
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
Re: Access Violation Tracking
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?
