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
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.
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
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 operati
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
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
>
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 acce
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 i
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?
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
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 in
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
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 t
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 c
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
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 prob
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
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
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 th
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 lea
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 ge
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;
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 su
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
calli
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 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.
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
h
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
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 throu
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 ment
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 throu
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 t
32 matches
Mail list logo
