Re: Fix D's segfaults!
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.
Re: Fix D's segfaults!
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" : 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
Re: Fix D's segfaults!
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
Re: Fix D's segfaults!
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`.
Re: Fix D's segfaults!
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.
Re: Fix D's segfaults!
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
Re: Fix D's segfaults!
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
Re: Fix D's segfaults!
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" : 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?
Re: Fix D's segfaults!
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" : 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).
Re: Fix D's segfaults!
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" : > 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. > >
