www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Fix D's segfaults!

reply Johnson Jones <JJ Dynomite.com> writes:
D has a major issue with segfaults! It always reports the fault 
in the lowest function that it occurs! This is completely useless!

std.file.FileException std\file.d(755): Attempting to rename file 
X.lib to Y.lib: The system cannot find the file specified.
----------------
0x0041015E
0x00402C69
0x004025A3
0x00413ECF
0x00413E93
0x00413D94
0x0040DAD7
0x76D78744 in BaseThreadInitThunk
0x76FD582D in RtlGetAppContainerNamedObjectPath
0x76FD57FD in RtlGetAppContainerNamedObjectPath

This tells me nothing about where the error occurred in *my* 
program!

Dmd needs to be modified so that errors try to show from the 
source code. This should be obvious the reasons, if it is not 
possible, make it possible! There are no excuses why dmd should 
make me go on an easter egg hunt when a seg fault occurs.
Aug 20 2017
next sibling parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
This is not segfault.  This is an uncatched exception.  So it is your
error. You does not do proper error handling. But still IIRC you should be
able to see place where things go wrong

Dne 20. 8. 2017 8:06 odpoledne napsal u=C5=BEivatel "Johnson Jones via
Digitalmars-d" <digitalmars-d puremagic.com>:


 D has a major issue with segfaults! It always reports the fault in the
 lowest function that it occurs! This is completely useless!

 std.file.FileException std\file.d(755): Attempting to rename file X.lib
 to Y.lib: The system cannot find the file specified.
 ----------------
 0x0041015E
 0x00402C69
 0x004025A3
 0x00413ECF
 0x00413E93
 0x00413D94
 0x0040DAD7
 0x76D78744 in BaseThreadInitThunk
 0x76FD582D in RtlGetAppContainerNamedObjectPath
 0x76FD57FD in RtlGetAppContainerNamedObjectPath

 This tells me nothing about where the error occurred in *my* program!

 Dmd needs to be modified so that errors try to show from the source code.
 This should be obvious the reasons, if it is not possible, make it
 possible! There are no excuses why dmd should make me go on an easter egg
 hunt when a seg fault occurs.
Aug 20 2017
parent reply Johnson Jones <JJ Dynomite.com> writes:
On Sunday, 20 August 2017 at 18:35:07 UTC, Daniel Kozak wrote:

 This is not segfault.  This is an uncatched exception.  So it 
 is your error. You does not do proper error handling. But still 
 IIRC you should be able to see place where things go wrong

 Dne 20. 8. 2017 8:06 odpoledne napsal uživatel "Johnson Jones 
 via Digitalmars-d" <digitalmars-d puremagic.com>:


 D has a major issue with segfaults! It always reports the 
 fault in the lowest function that it occurs! This is 
 completely useless!

 std.file.FileException std\file.d(755): Attempting to rename 
 file X.lib to Y.lib: The system cannot find the file specified.
 ----------------
 0x0041015E
 0x00402C69
 0x004025A3
 0x00413ECF
 0x00413E93
 0x00413D94
 0x0040DAD7
 0x76D78744 in BaseThreadInitThunk
 0x76FD582D in RtlGetAppContainerNamedObjectPath
 0x76FD57FD in RtlGetAppContainerNamedObjectPath

 This tells me nothing about where the error occurred in *my* 
 program!

 Dmd needs to be modified so that errors try to show from the 
 source code. This should be obvious the reasons, if it is not 
 possible, make it possible! There are no excuses why dmd 
 should make me go on an easter egg hunt when a seg fault 
 occurs.




Um,

That was just an example, the same type of output occurs with 
segfaults or any error/crash that D outputs stuff trying to be 
"helpful".

Anyways, your missing the point. You expect me to write 
try/catches in every level of my program to create the 
granularity one needs to simply get the location the error 
occured in? Where is that exactly?

How hard is it for dmd to know if 
std.file.FileException std\file.d occurs in the code I created or 
somewhere else? It should be able to say "Hey, that is part of a 
standard library or other non-user component, let me try to walk 
back a little and see if I can find a location in the user code 
that led to this problem".

This should be quite easy with a stacktrace, simply walk back 
until the location is in user code.

So, regardless of anything, D telling me stuff like "Hey, your 
error occurred in phobos" doesn't tell me shit except the error 
occurred in phobos. I'm still looking for easter eggs, and I 
don't like easter(which is why I don't capitalize it).
Aug 20 2017
next sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Sunday, 20 August 2017 at 19:14:10 UTC, Johnson Jones wrote:

 Dne 20. 8. 2017 8:06 odpoledne napsal uživatel "Johnson Jones 
 via Digitalmars-d" <digitalmars-d puremagic.com>:


 D has a major issue with segfaults! It always reports the 
 fault in the lowest function that it occurs! This is 
 completely useless!

 std.file.FileException std\file.d(755): Attempting to rename 
 file X.lib to Y.lib: The system cannot find the file 
 specified.
 ----------------
 0x0041015E
 0x00402C69
 0x004025A3
 0x00413ECF
 0x00413E93
 0x00413D94
 0x0040DAD7
 0x76D78744 in BaseThreadInitThunk
 0x76FD582D in RtlGetAppContainerNamedObjectPath
 0x76FD57FD in RtlGetAppContainerNamedObjectPath






[..]


 This should be quite easy with a stacktrace, simply walk back 
 until the location is in user code.


You are looking at the stack trace. The reason you don't see line 
numbers is probably that you did not compile with debugging 
information on?
Aug 20 2017
parent reply Shachar Shemesh <shachar weka.io> writes:
On 20/08/17 22:34, Bastiaan Veelo wrote:

 On Sunday, 20 August 2017 at 19:14:10 UTC, Johnson Jones wrote:

 Dne 20. 8. 2017 8:06 odpoledne napsal uživatel "Johnson Jones via 
 Digitalmars-d" <digitalmars-d puremagic.com>:


 D has a major issue with segfaults! It always reports the fault in 
 the lowest function that it occurs! This is completely useless!

 std.file.FileException std\file.d(755): Attempting to rename file 
 X.lib to Y.lib: The system cannot find the file specified.
 ----------------
 0x0041015E
 0x00402C69
 0x004025A3
 0x00413ECF
 0x00413E93
 0x00413D94
 0x0040DAD7
 0x76D78744 in BaseThreadInitThunk
 0x76FD582D in RtlGetAppContainerNamedObjectPath
 0x76FD57FD in RtlGetAppContainerNamedObjectPath






 
 [..]
 

 This should be quite easy with a stacktrace, simply walk back until 
 the location is in user code.


 
 You are looking at the stack trace. The reason you don't see line 
 numbers is probably that you did not compile with debugging information on?


No. It's the same problem as https://issues.dlang.org/show_bug.cgi?id=17727

It's a bug in DMD.

Shachar
Aug 21 2017
parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Monday, 21 August 2017 at 08:11:15 UTC, Shachar Shemesh wrote:

 On 20/08/17 22:34, Bastiaan Veelo wrote:

 You are looking at the stack trace. The reason you don't see 
 line numbers is probably that you did not compile with 
 debugging information on?


 No. It's the same problem as 
 https://issues.dlang.org/show_bug.cgi?id=17727

 It's a bug in DMD.

 Shachar


I see, thanks.
Aug 21 2017
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 08/20/2017 12:14 PM, Johnson Jones wrote:


 Dmd needs to be modified so that errors try to show from the source
 code. This should be obvious the reasons, if it is not possible, make
 it possible! There are no excuses why dmd should make me go on an
 easter egg hunt when a seg fault occurs.






You can open an enhancement request at

   https://issues.dlang.org/enter_bug.cgi

I don't know how well it works with D but what I used to do with C++ was 
to put a break point at Exception constructor, which would give me the 
useful stack to go back to my own code.

Ali
Aug 20 2017
next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sunday, August 20, 2017 12:35:45 Ali Çehreli via Digitalmars-d wrote:

 On 08/20/2017 12:14 PM, Johnson Jones wrote:
  >>> Dmd needs to be modified so that errors try to show from the source
  >>> code. This should be obvious the reasons, if it is not possible, make
  >>> it possible! There are no excuses why dmd should make me go on an
  >>> easter egg hunt when a seg fault occurs.

 You can open an enhancement request at

    https://issues.dlang.org/enter_bug.cgi

 I don't know how well it works with D but what I used to do with C++ was
 to put a break point at Exception constructor, which would give me the
 useful stack to go back to my own code.


With the stacktrace, he should be able to know where in his code the problem
is right now. But he doesn't seem to have any debug information whatsoever,
so his stack trace is useless. If I run the program

    module test;

    import std.file;

    void main()
    {
        rename("does_not_exist_1", "does_not_exist_2");
    }

on my system (which is FreeBSD), I get

std.file.FileException std/file.d(763): does_not_exist_2: No such file or 
directory
----------------
??:?  trusted bool std.file.cenforce!(bool).cenforce(bool, const(char)[], 
const(char)*, immutable(char)[], ulong) [0x476c26]
??:?  trusted void std.file.renameImpl(const(char)[], const(char)[], 
const(char)*, const(char)*) [0x4759e6]
??:?  safe void std.file.rename!(immutable(char)[], immutable(char)
[]).rename(immutable(char)[], immutable(char)[]) [0x470304]
??:? _Dmain [0x470202]

which is much better but still not where it should be. The line numbers are
missing, and for some reason, the module name isn't on _Dmain. However, if I
do

    module test;

    import std.file;

    void main()
    {
        foo();
    }

    void foo()
    {
        rename("does_not_exist_1", "does_not_exist_2");
    }

then I get

std.file.FileException std/file.d(763): does_not_exist_2: No such file or 
directory
----------------
??:?  trusted bool std.file.cenforce!(bool).cenforce(bool, const(char)[], 
const(char)*, immutable(char)[], ulong) [0x476c66]
??:?  trusted void std.file.renameImpl(const(char)[], const(char)[], 
const(char)*, const(char)*) [0x475a26]
??:?  safe void std.file.rename!(immutable(char)[], immutable(char)
[]).rename(immutable(char)[], immutable(char)[]) [0x470344]
??:? void test.foo() [0x470242]
??:? _Dmain [0x47020c]

which _does_ have the module name on the function that main calls. So, the
lack of module name must be a quirk of _Dmain - probably tied to the fact
that there's only supposed to be one. But the line numbers are still
missing, which they really shouldn't be. I know that that's been a problem
in the past on *nix systems, but I'd thought that it had been fixed. So, I
don't know what the problem is. Regardless, I think that it should
definitely be considered a bug if the line numbers don't show up.

But in spite of the lack of line numbers, what I have here is way better
than what the OP sees. So, he's doing something differently, but I don't
know what. But based on what I'm seeing, it should be possible for the OP to
get a much better stack trace right now. It's just a question of figuring
out what he's doing differently that causes his stack traces to show up with
just addresses.

- Jonathan M Davis
Aug 20 2017
parent user1234 <user1234 us.er> writes:
On Sunday, 20 August 2017 at 20:20:30 UTC, Jonathan M Davis wrote:

 On Sunday, August 20, 2017 12:35:45 Ali Çehreli via 
 Digitalmars-d wrote:

 On 08/20/2017 12:14 PM, Johnson Jones wrote:
  >>> Dmd needs to be modified so that errors try to show from 
 the source
  >>> code. This should be obvious the reasons, if it is not 
 possible, make
  >>> it possible! There are no excuses why dmd should make me 
 go on an
  >>> easter egg hunt when a seg fault occurs.

 You can open an enhancement request at

    https://issues.dlang.org/enter_bug.cgi
 


 [...]
 But in spite of the lack of line numbers
 [...]


The lack of line number is simply caused by phobos as a static 
library which is build without the -g switch. The only i see way 
to solve this is to

1/ ship dmd with an additional libphobos2-debug.{a|lib}
2/ change the compiler so that when the -g switch is passed, it 
links against the version that has the "-debug" suffix.

This or another trick that would have the same effect.

ATM we have to build the phobos-debug ourselves if we want to see 
the line nums.
Aug 20 2017
prev sibling parent Nemanja Boric <4burgos gmail.com> writes:
On Sunday, 20 August 2017 at 19:35:45 UTC, Ali Çehreli wrote:

 On 08/20/2017 12:14 PM, Johnson Jones wrote:


 Dmd needs to be modified so that errors try to show from






 the source

 code. This should be obvious the reasons, if it is not






 possible, make

 it possible! There are no excuses why dmd should make me go






 on an

 easter egg hunt when a seg fault occurs.






 You can open an enhancement request at

   https://issues.dlang.org/enter_bug.cgi

 I don't know how well it works with D but what I used to do 
 with C++ was to put a break point at Exception constructor, 
 which would give me the useful stack to go back to my own code.

 Ali


The usual trick is to set the breakpoint on `_d_throwdwarf`.
Aug 21 2017
prev sibling parent Nemanja Boric <4burgos gmail.com> writes:
On Sunday, 20 August 2017 at 18:01:06 UTC, Johnson Jones wrote:

 D has a major issue with segfaults! It always reports the fault 
 in the lowest function that it occurs! This is completely 
 useless!

 std.file.FileException std\file.d(755): Attempting to rename 
 file X.lib to Y.lib: The system cannot find the file specified.
 ----------------
 0x0041015E
 0x00402C69
 0x004025A3
 0x00413ECF
 0x00413E93
 0x00413D94
 0x0040DAD7
 0x76D78744 in BaseThreadInitThunk
 0x76FD582D in RtlGetAppContainerNamedObjectPath
 0x76FD57FD in RtlGetAppContainerNamedObjectPath

 This tells me nothing about where the error occurred in *my* 
 program!

 Dmd needs to be modified so that errors try to show from the 
 source code. This should be obvious the reasons, if it is not 
 possible, make it possible! There are no excuses why dmd should 
 make me go on an easter egg hunt when a seg fault occurs.


There are many issues and ideas reported in bugzilla about this: 
https://issues.dlang.org/show_bug.cgi?id=14885 
https://issues.dlang.org/show_bug.cgi?id=5944 etc. Here's the one 
that specifically tackles the `FileException` and the problem 
you're reporting: https://issues.dlang.org/show_bug.cgi?id=13543
Aug 21 2017