www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - prog segfaults

reply Ant <duitoolkit yahoo.ca> writes:
(for sure I'm overseeing something)

bug report (?) should I post on the bugs group?

I was trying to confirm we need to initialize objects 
pass with "out" and the executable for this just segfaults:


class A
{
	int a;
}

void f(out A a)
{
	assert(a); // OK IF REPLACE BY assert(a!==null);
	printf("hello\n");
}

void main()
{
	A a = new A();
	f(a);
}


Ant





















here is the 10 lines version:
class A{int a;}

void f(out A a)
{
	assert(a);
	printf("hello\n");
}

void main()
{A a = new A();f(a);}
Jul 27 2004
parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 27 Jul 2004 21:09:07 -0400, Ant wrote:


 class A
 {
 	int a;
 }
 
 void f(out A a)
 {
 	assert(a); // OK IF REPLACE BY assert(a!==null);
 	printf("hello\n");
 }
 
 void main()
 {
 	A a = new A();
 	f(a);
 }


When function 'f' gets its parameters, the 'a' will be null because of the
'out' option. Even though you passed a new instance of A to it, the out
option will initialize it to null. The assert is probably redundant as this
is the expected behaviour of the language. 

Try this code, it should crash with an access violation on the second
writef() call because the f() call's out option initialized it.

<code>
 import std.stdio;
 class A
 {
    int x;
 }

 void f(out A a)
 {
    assert(a is null);
    writef("hello\n");
 }

 void main()
 {
    A a = new A;
    a.x = 1;
    writef("before= %d\n", a.x);
    f(a);
    writef("after = %d\n", a.x);
 }
</code>

-- 
Derek
Melbourne, Australia
28/Jul/04 12:12:07 PM
Jul 27 2004
parent reply Ant <duitoolkit yahoo.ca> writes:
On Wed, 28 Jul 2004 12:18:37 +1000, Derek Parnell wrote:


 On Tue, 27 Jul 2004 21:09:07 -0400, Ant wrote:
 

 class A
 {
 	int a;
 }
 
 void f(out A a)
 {
 	assert(a); // OK IF REPLACE BY assert(a!==null);
 	printf("hello\n");
 }
 
 void main()
 {
 	A a = new A();
 	f(a);
 }


 
 When function 'f' gets its parameters, the 'a' will be null because of the
 'out' option. Even though you passed a new instance of A to it, the out
 option will initialize it to null. The assert is probably redundant as this
 is the expected behaviour of the language. 




yes, that's what I was trying to confirm.

but the program shouldn't segfault!
it should print and assertion failure. (?)

Ant
Jul 27 2004
parent reply Andy Friesen <andy ikagames.com> writes:
Ant wrote:

 On Wed, 28 Jul 2004 12:18:37 +1000, Derek Parnell wrote:
 

void f(out A a)
{
	assert(a); // OK IF REPLACE BY assert(a!==null);
	printf("hello\n");
}


When function 'f' gets its parameters, the 'a' will be null because of the
'out' option. Even though you passed a new instance of A to it, the out
option will initialize it to null. The assert is probably redundant as this
is the expected behaviour of the language. 


 
 yes, that's what I was trying to confirm.
 
 but the program shouldn't segfault!
 it should print and assertion failure. (?)


assert(a); is a special case in the language: it is not a boolean 
not-null test, it runs A's invariant to assert that 'a' is correct.

Still, you would think that an assertion failure would trip, since part 
of Object.invariant is "assert(this!==null);"

  -- andy
Jul 27 2004
parent reply Ant <duitoolkit yahoo.ca> writes:
On Tue, 27 Jul 2004 20:02:06 -0700, Andy Friesen wrote:


 
 assert(a); is a special case in the language: it is not a boolean 
 not-null test, it runs A's invariant to assert that 'a' is correct.


I didn't know that, cheking documentation ... checked, good!


 
 Still, you would think that an assertion failure would trip, since part 
 of Object.invariant is "assert(this!==null);"
 


so looks like a bug, smells like a bug, is it a bug?

Ant
Jul 27 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Ant" <duitoolkit yahoo.ca> wrote in message
news:pan.2004.07.28.03.06.34.780054 yahoo.ca...

 On Tue, 27 Jul 2004 20:02:06 -0700, Andy Friesen wrote:


 assert(a); is a special case in the language: it is not a boolean
 not-null test, it runs A's invariant to assert that 'a' is correct.


 I didn't know that, cheking documentation ... checked, good!


 Still, you would think that an assertion failure would trip, since part
 of Object.invariant is "assert(this!==null);"


 so looks like a bug, smells like a bug, is it a bug?


No. assert(a) doesn't bother checking to see if a is null before calling the
invariant, because the hardware will do that for you. Why duplicate what the
hardware does?
Jul 27 2004
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 27 Jul 2004 20:41:56 -0700, Walter wrote:


 "Ant" <duitoolkit yahoo.ca> wrote in message
 news:pan.2004.07.28.03.06.34.780054 yahoo.ca...

 On Tue, 27 Jul 2004 20:02:06 -0700, Andy Friesen wrote:


 assert(a); is a special case in the language: it is not a boolean
 not-null test, it runs A's invariant to assert that 'a' is correct.


 I didn't know that, cheking documentation ... checked, good!


 Still, you would think that an assertion failure would trip, since part
 of Object.invariant is "assert(this!==null);"


 so looks like a bug, smells like a bug, is it a bug?


 
 No. assert(a) doesn't bother checking to see if a is null before calling the
 invariant, because the hardware will do that for you. Why duplicate what the
 hardware does?


Because assert() gives us filename and line number, but "Access Violation"
doesn't.

-- 
Derek
Melbourne, Australia
28/Jul/04 2:29:38 PM
Jul 27 2004
next sibling parent Regan Heath <regan netwin.co.nz> writes:
On Wed, 28 Jul 2004 14:35:05 +1000, Derek Parnell <derek psych.ward> wrote:

 On Tue, 27 Jul 2004 20:41:56 -0700, Walter wrote:


 "Ant" <duitoolkit yahoo.ca> wrote in message
 news:pan.2004.07.28.03.06.34.780054 yahoo.ca...

 On Tue, 27 Jul 2004 20:02:06 -0700, Andy Friesen wrote:


 assert(a); is a special case in the language: it is not a boolean
 not-null test, it runs A's invariant to assert that 'a' is correct.


 I didn't know that, cheking documentation ... checked, good!


 Still, you would think that an assertion failure would trip, since 
 part
 of Object.invariant is "assert(this!==null);"


 so looks like a bug, smells like a bug, is it a bug?


 No. assert(a) doesn't bother checking to see if a is null before 
 calling the
 invariant, because the hardware will do that for you. Why duplicate 
 what the
 hardware does?


 Because assert() gives us filename and line number, but "Access 
 Violation"
 doesn't.


Good point, in fact in debug mode I want all errors to give a file and 
line number, including access violation.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 27 2004
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:ce7aei$2une$1 digitaldaemon.com...

 On Tue, 27 Jul 2004 20:41:56 -0700, Walter wrote:


 "Ant" <duitoolkit yahoo.ca> wrote in message
 news:pan.2004.07.28.03.06.34.780054 yahoo.ca...

 On Tue, 27 Jul 2004 20:02:06 -0700, Andy Friesen wrote:


 assert(a); is a special case in the language: it is not a boolean
 not-null test, it runs A's invariant to assert that 'a' is correct.


 I didn't know that, cheking documentation ... checked, good!


 Still, you would think that an assertion failure would trip, since








part

 of Object.invariant is "assert(this!==null);"


 so looks like a bug, smells like a bug, is it a bug?


 No. assert(a) doesn't bother checking to see if a is null before calling




the

 invariant, because the hardware will do that for you. Why duplicate what




the

 hardware does?


 Because assert() gives us filename and line number, but "Access Violation"
 doesn't.


Run it under the debugger, and the debugger will open up a window and put
the cursor on it <g>.
Jul 27 2004
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 27 Jul 2004 22:53:31 -0700, Walter wrote:


 "Derek Parnell" <derek psych.ward> wrote in message
 news:ce7aei$2une$1 digitaldaemon.com...

 On Tue, 27 Jul 2004 20:41:56 -0700, Walter wrote:


 "Ant" <duitoolkit yahoo.ca> wrote in message
 news:pan.2004.07.28.03.06.34.780054 yahoo.ca...

 On Tue, 27 Jul 2004 20:02:06 -0700, Andy Friesen wrote:


 assert(a); is a special case in the language: it is not a boolean
 not-null test, it runs A's invariant to assert that 'a' is correct.


 I didn't know that, cheking documentation ... checked, good!


 Still, you would think that an assertion failure would trip, since








 part

 of Object.invariant is "assert(this!==null);"


 so looks like a bug, smells like a bug, is it a bug?


 No. assert(a) doesn't bother checking to see if a is null before calling




 the

 invariant, because the hardware will do that for you. Why duplicate what




 the

 hardware does?


 Because assert() gives us filename and line number, but "Access Violation"
 doesn't.


 
 Run it under the debugger, and the debugger will open up a window and put
 the cursor on it <g>.


Sorry, too glib. Not impressed.

Why bother having assert give this info?

And which "the debugger" are you referring to?

-- 
Derek
Melbourne, Australia
28/Jul/04 4:40:23 PM
Jul 27 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:ce7ijg$30vm$1 digitaldaemon.com...

 Because assert() gives us filename and line number, but "Access






Violation"

 doesn't.


 Run it under the debugger, and the debugger will open up a window and




put

 the cursor on it <g>.


 Sorry, too glib. Not impressed.

 Why bother having assert give this info?


Because debuggers don't work off of asserts.


 And which "the debugger" are you referring to?


Most any debugger will do it. In fact, it's one of the main features of a
semi-decent debugger. I can't remember any protected mode debugger that
didn't do it. Debuggers will also give a stack trace, which is so useful
that sometimes I'll replace the assert with a *(char*)0=0; just to run it
under a debugger to get the stack trace.

GPFs have an undeservedly bad rap. There's nothing inherently worse about it
than an assert failure. They're really the same thing, and the GPF has the
nice feature that you get such checking with 0 extra overhead (unlike
asserts). The GPF does in hardware what the assert does in software, that's
all.
Jul 28 2004
parent reply Daniel Horn <hellcatv hotmail.com> writes:
can't assert print the stack (if you have the frame pointer)?
I mean you just need some logic that does the same thing that the 
debugger would do...and call that on an assert...
it's useless to have an assert not throw a signal otherwise...usually 
the assert isn't where the problem is occuring, but n frame(s) above it.


Walter wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:ce7ijg$30vm$1 digitaldaemon.com...
 

Because assert() gives us filename and line number, but "Access






 
 Violation"
 

doesn't.


Run it under the debugger, and the debugger will open up a window and




 
 put
 

the cursor on it <g>.


Sorry, too glib. Not impressed.

Why bother having assert give this info?


 
 
 Because debuggers don't work off of asserts.
 
 

And which "the debugger" are you referring to?


 
 
 Most any debugger will do it. In fact, it's one of the main features of a
 semi-decent debugger. I can't remember any protected mode debugger that
 didn't do it. Debuggers will also give a stack trace, which is so useful
 that sometimes I'll replace the assert with a *(char*)0=0; just to run it
 under a debugger to get the stack trace.
 
 GPFs have an undeservedly bad rap. There's nothing inherently worse about it
 than an assert failure. They're really the same thing, and the GPF has the
 nice feature that you get such checking with 0 extra overhead (unlike
 asserts). The GPF does in hardware what the assert does in software, that's
 all.
Jul 28 2004
parent "Walter" <newshound digitalmars.com> writes:
"Daniel Horn" <hellcatv hotmail.com> wrote in message
news:ce8nrb$es2$2 digitaldaemon.com...

 can't assert print the stack (if you have the frame pointer)?
 I mean you just need some logic that does the same thing that the
 debugger would do...and call that on an assert...
 it's useless to have an assert not throw a signal otherwise...usually
 the assert isn't where the problem is occuring, but n frame(s) above it.


It's not so easy since the debug data needed is sometimes separate. The
debugger has the debug data, and so can do a stack trace easilly. That's why
I sometimes replace an assert with *(char*)0=0;.
Jul 28 2004
prev sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <ce7fjr$30a6$1 digitaldaemon.com>, Walter says...

Run it under the debugger, and the debugger will open up a window and put
the cursor on it <g>.


Is it possible under linux?
(I know I asked this before and nobody answer, I promiss I won't ask again)

Walter sais he uses gdb but I can't convince it to show the 
D source (no problem with C source).

Ant
Jul 28 2004
next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
Ant wrote:


 In article <ce7fjr$30a6$1 digitaldaemon.com>, Walter says...

Run it under the debugger, and the debugger will open up a window and put
the cursor on it <g>.


 
 Is it possible under linux?
 (I know I asked this before and nobody answer, I promiss I won't ask
 again)
 
 Walter sais he uses gdb but I can't convince it to show the
 D source (no problem with C source).
 
 Ant


I've been using gdb but I've noticed 
1) the source doesn't show up - annoying but not a big deal for me since I
don't have much code
2) sometimes the stack traces printed out by "bt" look pretty messed up even
for simple things
3) I can't look at variables when stopped
Jul 28 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <ce86dc$7pd$1 digitaldaemon.com>, Ben Hinkle says...

I've been using gdb but I've noticed 
1) the source doesn't show up - annoying but not a big deal for me since I
don't have much code
2) sometimes the stack traces printed out by "bt" look pretty messed up even
for simple things
3) I can't look at variables when stopped


So, why do you use it? What can you get?
(It's an honest question. not a joke)
What do you get from it?

I've been using it (with DDD front end) to debug the interface with
C (on DUI) but it doesn't help me with D.

Ant
Jul 28 2004
parent reply Ben Hinkle <bhinkle4 juno.com> writes:
Ant wrote:


 In article <ce86dc$7pd$1 digitaldaemon.com>, Ben Hinkle says...

I've been using gdb but I've noticed
1) the source doesn't show up - annoying but not a big deal for me since I
don't have much code
2) sometimes the stack traces printed out by "bt" look pretty messed up
even for simple things
3) I can't look at variables when stopped


 
 So, why do you use it? What can you get?
 (It's an honest question. not a joke)
 What do you get from it?


usually the stack trace is correct. that's all I use it for.
 

 I've been using it (with DDD front end) to debug the interface with
 C (on DUI) but it doesn't help me with D.
 
 Ant
Jul 28 2004
parent Ant <duitoolkit yahoo.ca> writes:
On Wed, 28 Jul 2004 12:22:35 -0400, Ben Hinkle wrote:


 
 usually the stack trace is correct. that's all I use it for.
  


thanks, Ben and Walter and guys I can see the stack! :)
(finally :p)

Ant
Jul 28 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:ce83ht$6in$1 digitaldaemon.com...

 In article <ce7fjr$30a6$1 digitaldaemon.com>, Walter says...

Run it under the debugger, and the debugger will open up a window and put
the cursor on it <g>.


 Is it possible under linux?
 (I know I asked this before and nobody answer, I promiss I won't ask


again)

 Walter sais he uses gdb but I can't convince it to show the
 D source (no problem with C source).


That's because I've been lazy and have not gotten the debug data written out
correctly in the elf format. gdb will, however, give the stack trace, and
with the 'disassemble' command will show you which instruction failed, which
if you turn optimization off is pretty easy to spot which line it is on.
Jul 28 2004
prev sibling parent reply Nick <Nick_member pathlink.com> writes:
Dixit Derek Parnell says:


On Tue, 27 Jul 2004 20:41:56 -0700, Walter wrote:

 
 No. assert(a) doesn't bother checking to see if a is null before calling the
 invariant, because the hardware will do that for you. Why duplicate what the
 hardware does?


Because assert() gives us filename and line number, but "Access Violation"
doesn't.


Also, you can try/catch the assert if you're so inclined.

Nick
Jul 28 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Nick" <Nick_member pathlink.com> wrote in message
news:ce8ubj$if6$1 digitaldaemon.com...

 Dixit Derek Parnell says:


On Tue, 27 Jul 2004 20:41:56 -0700, Walter wrote:

 No. assert(a) doesn't bother checking to see if a is null before






calling the

 invariant, because the hardware will do that for you. Why duplicate






what the

 hardware does?


Because assert() gives us filename and line number, but "Access




Violation"

doesn't.


 Also, you can try/catch the assert if you're so inclined.


You can catch the access violations, too!
Jul 28 2004
parent reply Nick <dont like.spam> writes:
Walter wrote:

Also, you can try/catch the assert if you're so inclined.


 
 You can catch the access violations, too!


Well, it doesn't seem to work for me... (using linux). Running the 
following just gives a segmentation fault:

import std.stdio;
class A {}
void main()
{
   A a;
   try
     {
       assert(a);
     }
   catch
     {
       writefln("catch");
     }
}

Perhaps it's just a linux bug?

Nick
Jul 28 2004
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Nick wrote:

 Walter wrote:
 

 Also, you can try/catch the assert if you're so inclined.


 You can catch the access violations, too!


 
 Well, it doesn't seem to work for me... (using linux). Running the 
 following just gives a segmentation fault:
 
 import std.stdio;
 class A {}
 void main()
 {
   A a;
   try
     {
       assert(a);
     }
   catch
     {
       writefln("catch");
     }
 }
 
 Perhaps it's just a linux bug?


No.  The problem here is exactly the "feature" that Walter is using. 
Your assert is failing because of a segmentation fault, because the line 
is attempting to read data at address 0.  A segmentation fault is caught 
by the operating system, not the program, an as such doesn't call under 
the try/catch paradigm.

To catch a segfault in linux, you have to register a signal handler for 
that.  See "man signal" or "man sigaction".

I wonder if you can throw an exception inside of a signal handler, and 
have it caught by the failing code?  Something like this:



* WARNING WARNING WARNING *
* I have no idea if this would work... *
void main() {
   register_signal_handler(SIG_SEGV, &segfault_handler);

   A a;
   try {
     assert(a);
   } catch(SegFaultException e) {
     // whatever
   }
}

void segfault_handler() {
   throw new SegFaultException();
}
Jul 28 2004
parent "Walter" <newshound digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:ce94kf$kti$1 digitaldaemon.com...

 Nick wrote:

 Walter wrote:


 Also, you can try/catch the assert if you're so inclined.


 You can catch the access violations, too!


 Well, it doesn't seem to work for me... (using linux). Running the
 following just gives a segmentation fault:

 import std.stdio;
 class A {}
 void main()
 {
   A a;
   try
     {
       assert(a);
     }
   catch
     {
       writefln("catch");
     }
 }

 Perhaps it's just a linux bug?


 No.  The problem here is exactly the "feature" that Walter is using.
 Your assert is failing because of a segmentation fault, because the line
 is attempting to read data at address 0.  A segmentation fault is caught
 by the operating system, not the program, an as such doesn't call under
 the try/catch paradigm.

 To catch a segfault in linux, you have to register a signal handler for
 that.  See "man signal" or "man sigaction".

 I wonder if you can throw an exception inside of a signal handler, and
 have it caught by the failing code?  Something like this:



 * WARNING WARNING WARNING *
 * I have no idea if this would work... *
 void main() {
    register_signal_handler(SIG_SEGV, &segfault_handler);

    A a;
    try {
      assert(a);
    } catch(SegFaultException e) {
      // whatever
    }
 }

 void segfault_handler() {
    throw new SegFaultException();
 }


The catch will work under Windows, I just haven't implemented the linux end.
I think your scheme will work.
Jul 28 2004
prev sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <ce77fg$2sh7$1 digitaldaemon.com>, Walter says...

"Ant" <duitoolkit yahoo.ca> wrote in message
news:pan.2004.07.28.03.06.34.780054 yahoo.ca...

 On Tue, 27 Jul 2004 20:02:06 -0700, Andy Friesen wrote:


 assert(a); is a special case in the language: it is not a boolean
 not-null test, it runs A's invariant to assert that 'a' is correct.


 I didn't know that, cheking documentation ... checked, good!


 Still, you would think that an assertion failure would trip, since part
 of Object.invariant is "assert(this!==null);"


 so looks like a bug, smells like a bug, is it a bug?


No. assert(a) doesn't bother checking to see if a is null before calling the
invariant, because the hardware will do that for you. Why duplicate what the
hardware does?


To give a line number and file name to the poor guy that spends hours
looking at his or someone else's code?

Ant
Jul 28 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:ce838c$6fe$1 digitaldaemon.com...

 In article <ce77fg$2sh7$1 digitaldaemon.com>, Walter says...

No. assert(a) doesn't bother checking to see if a is null before calling




the

invariant, because the hardware will do that for you. Why duplicate what




the

hardware does?


 To give a line number and file name to the poor guy that spends hours
 looking at his or someone else's code?


The debugger can do that for you.
Jul 28 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 28 Jul 2004 13:04:12 -0700, Walter <newshound digitalmars.com> 
wrote:

 "Ant" <Ant_member pathlink.com> wrote in message
 news:ce838c$6fe$1 digitaldaemon.com...

 In article <ce77fg$2sh7$1 digitaldaemon.com>, Walter says...

No. assert(a) doesn't bother checking to see if a is null before 


 calling


 the

invariant, because the hardware will do that for you. Why duplicate 


 what


 the

hardware does?


 To give a line number and file name to the poor guy that spends hours
 looking at his or someone else's code?


 The debugger can do that for you.


Ok, but, now assume the piece of software is a mail server, which you have 
written, which is running on a large production system.

It crashes due to a bug which is not reproducable due to it's specific 
nature, i.e. under heavy load on that specific operating system etc.

You cannot use a debugger to find this bug. You could use one on a core 
_if_ it dropped one (it is common for systems to be configured not to drop 
one - this is experience talking)

What you ideally want is for your application to do it's own debugging. On 
the event of an assert or Access Violation you catch it, and write a log 
file containing the file and line number, a complete stack trace, and 
excerpts from the various log files it writes, you notify the watching 
process and die. The watcher grabs the crash log, emails it to the 
sysadmin, and restarts the mail server.

Is all that possible with D currently? I believe most of it is, I don't 
think I can get the __FILE__ and __LINE__ data.

A nice cross platform stack trace lib would be ideal.

A nice cross platform assert and access violation (plus other signals) 
catching lib would be ideal.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 28 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsbvck2ao5a2sq9 digitalmars.com...

 To give a line number and file name to the poor guy that spends hours
 looking at his or someone else's code?


 The debugger can do that for you.


 Ok, but, now assume the piece of software is a mail server, which you have
 written, which is running on a large production system.

 It crashes due to a bug which is not reproducable due to it's specific
 nature, i.e. under heavy load on that specific operating system etc.

 You cannot use a debugger to find this bug. You could use one on a core
 _if_ it dropped one (it is common for systems to be configured not to drop
 one - this is experience talking)

 What you ideally want is for your application to do it's own debugging. On
 the event of an assert or Access Violation you catch it, and write a log
 file containing the file and line number, a complete stack trace, and
 excerpts from the various log files it writes, you notify the watching
 process and die. The watcher grabs the crash log, emails it to the
 sysadmin, and restarts the mail server.

 Is all that possible with D currently? I believe most of it is, I don't
 think I can get the __FILE__ and __LINE__ data.


Yes. First of all, you can catch access violations with the catch clause
(works under Windows, I haven't made it work under linux yet). Next, given
the address of where it faulted, it can be compared with the line number
info in the program's debug data to get the file/line. Normally, the
debugger does this for you, but there's no reason one cannot do it with a
specially written chunk of code that reads the debug data.
Jul 28 2004
next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 28 Jul 2004 19:33:48 -0700, Walter <newshound digitalmars.com> 
wrote:


 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsbvck2ao5a2sq9 digitalmars.com...

 To give a line number and file name to the poor guy that spends hours
 looking at his or someone else's code?


 The debugger can do that for you.


 Ok, but, now assume the piece of software is a mail server, which you 
 have
 written, which is running on a large production system.

 It crashes due to a bug which is not reproducable due to it's specific
 nature, i.e. under heavy load on that specific operating system etc.

 You cannot use a debugger to find this bug. You could use one on a core
 _if_ it dropped one (it is common for systems to be configured not to 
 drop
 one - this is experience talking)

 What you ideally want is for your application to do it's own debugging. 
 On
 the event of an assert or Access Violation you catch it, and write a log
 file containing the file and line number, a complete stack trace, and
 excerpts from the various log files it writes, you notify the watching
 process and die. The watcher grabs the crash log, emails it to the
 sysadmin, and restarts the mail server.

 Is all that possible with D currently? I believe most of it is, I don't
 think I can get the __FILE__ and __LINE__ data.


 Yes. First of all, you can catch access violations with the catch clause
 (works under Windows, I haven't made it work under linux yet).


Cool. Is "access violation" == SIGSEGV

Does it catch anything else as well? It would be cool if I could catch:

#define SIGINT          2       /* interrupt */
#define SIGILL          4       /* illegal instruction - invalid function 
image */
#define SIGFPE          8       /* floating point exception */
#define SIGSEGV         11      /* segment violation */
#define SIGTERM         15      /* Software termination signal from kill */
#define SIGBREAK        21      /* Ctrl-Break sequence */
#define SIGABRT         22      /* abnormal termination triggered by abort 
call */

(the above are just the windows signals)

If try/catch and exceptions are to be the error handling mechanism it 
makes sense that you can do all your error handling this way, including 
signals, access violations, asserts, etc.


 Next, given
 the address of where it faulted, it can be compared with the line number
 info in the program's debug data to get the file/line. Normally, the
 debugger does this for you, but there's no reason one cannot do it with a
 specially written chunk of code that reads the debug data.


Great, but, I have no idea how to do that. So either:
  - I have to wait till someone else does it and releases it.
  - I have to learn how.

or the third option, my favourite:
  - The compiler defines a 'char[] file' and 'uint line' which I can access.

Why is that so hard to do?

try {
}
catch {
   //access violation
   printf("Access Violation: %.*s:%d\n",file,line);
}

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 28 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsbvo8cpg5a2sq9 digitalmars.com...

 Cool. Is "access violation" == SIGSEGV

 Does it catch anything else as well? It would be cool if I could catch:

 #define SIGINT          2       /* interrupt */
 #define SIGILL          4       /* illegal instruction - invalid function
 image */
 #define SIGFPE          8       /* floating point exception */
 #define SIGSEGV         11      /* segment violation */
 #define SIGTERM         15      /* Software termination signal from kill


*/

 #define SIGBREAK        21      /* Ctrl-Break sequence */
 #define SIGABRT         22      /* abnormal termination triggered by abort
 call */

 (the above are just the windows signals)


Yes. If you want to see how it's done, see internal\deh.c function
_d_translate_se_to_d_exception()


 or the third option, my favourite:
   - The compiler defines a 'char[] file' and 'uint line' which I can


access.

 Why is that so hard to do?


I always thought __FILE__ and __LINE__ are just so ugly. But when you think
about it, __FILE__ and __LINE__ only really make sense for macros. Using
them directly is pointless, isn't it? Wouldn't it make sense to throw a
string, and then grep on that string if you can't remember where it came
from?

You can also simply write:
    assert(p != null);
and not generate a seg fault.
Jul 28 2004
next sibling parent reply "Mickey Finn" <horizon blackhole.net> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cea6oh$14c3$1 digitaldaemon.com...

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsbvo8cpg5a2sq9 digitalmars.com...

 Cool. Is "access violation" == SIGSEGV

 Does it catch anything else as well? It would be cool if I could catch:

 #define SIGINT          2       /* interrupt */
 #define SIGILL          4       /* illegal instruction - invalid




function

 image */
 #define SIGFPE          8       /* floating point exception */
 #define SIGSEGV         11      /* segment violation */
 #define SIGTERM         15      /* Software termination signal from kill


 */

 #define SIGBREAK        21      /* Ctrl-Break sequence */
 #define SIGABRT         22      /* abnormal termination triggered by




abort

 call */

 (the above are just the windows signals)


 Yes. If you want to see how it's done, see internal\deh.c function
 _d_translate_se_to_d_exception()


 or the third option, my favourite:
   - The compiler defines a 'char[] file' and 'uint line' which I can


 access.

 Why is that so hard to do?


 I always thought __FILE__ and __LINE__ are just so ugly. But when you


think

 about it, __FILE__ and __LINE__ only really make sense for macros. Using
 them directly is pointless, isn't it? Wouldn't it make sense to throw a
 string, and then grep on that string if you can't remember where it came
 from?


1) Sometimes the same exception message is used in multiple places, so it
can be hard to track down.
2) Sometimes you don't have the source, but still need to know the culprit
3) the message itself might be manufactured (via
localization/externalization) so wouldn't be found with a grep
4) it's very useful to place this information into a 'log' message, so you
can easily see what produced a message witthout having to scan the source.

etc.

If you're concerned about exposing the __FILE__ as a symbol, is it possible
to wrap it? Perhaps as an instrinsic function (like rol/ror)?
Jul 29 2004
parent "Mickey Finn" <horizon blackhole.net> writes:
 1) Sometimes the same exception message is used in multiple places, so it
 can be hard to track down.
 2) Sometimes you don't have the source, but still need to know the culprit
 3) the message itself might be manufactured (via
 localization/externalization) so wouldn't be found with a grep
 4) it's very useful to place this information into a 'log' message, so you
 can easily see what produced a message witthout having to scan the source.

 etc.


5) dmd.exe uses __FILE__ & __LINE__ itself: I just got this message from the
compiler :-)

Internal error: s2ir.c 457
Jul 29 2004
prev sibling next sibling parent reply Farmer <itsFarmer. freenet.de> writes:
"Walter" <newshound digitalmars.com> wrote in 
news:cea6oh$14c3$1 digitaldaemon.com:

 

 You can also simply write:
     assert(p != null);
 and not generate a seg fault.


Sure it does! (I checked with DMD 0.96)

You probably meant:
    assert(p isnot null);     // ;-)


Joking aside, exception stacktraces would be a boon to programmers. 
The pain with exceptions is that in well refactored code, exceptions are 
often thrown in on function, but that function is called via various code 
paths.
So you know where the exception was thrown and where it was caught, but you 
don't known what happened in between.
I for one, refused to use exceptions in C++ mainly for that reason. And the 
one time, I did use exceptions, I actually hacked the stacktrace in my code  
by hand and a little help from the preprocessor. 


The __FILE__, __LINE__ and especially __FUNCTION__ (non-standard) data is 
very handy for writting log files.  Please, consider that log files are 
*very* important to some people, so they create all this information by hand 
if a language doesn't provide it or in Java's case cannot produce it fast 
enough.



Farmer.
Jul 29 2004
parent reply Sean Kelly <sean f4.ca> writes:
In article <Xns9536AC639A46itsFarmer 63.105.9.61>, Farmer says...

So you know where the exception was thrown and where it was caught, but you 
don't known what happened in between.
I for one, refused to use exceptions in C++ mainly for that reason. And the 
one time, I did use exceptions, I actually hacked the stacktrace in my code  
by hand and a little help from the preprocessor. 


There have been articles written by very smart people on how to (in code)
generate stack traces in C++ when exceptions are thrown.  IIRC the conclusion
was that it's just not possible to do very well.  I agree that it would be nice
to have compiler support for stack traces when exceptions are thrown.


Sean
Jul 29 2004
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Sean Kelly wrote:

 In article <Xns9536AC639A46itsFarmer 63.105.9.61>, Farmer says...
 

So you know where the exception was thrown and where it was caught, but you 
don't known what happened in between.
I for one, refused to use exceptions in C++ mainly for that reason. And the 
one time, I did use exceptions, I actually hacked the stacktrace in my code  
by hand and a little help from the preprocessor. 


 
 There have been articles written by very smart people on how to (in code)
 generate stack traces in C++ when exceptions are thrown.  IIRC the conclusion
 was that it's just not possible to do very well.  I agree that it would be nice
 to have compiler support for stack traces when exceptions are thrown.


It is possible to do a portable stack trace if you know the starting 
address and size of every function in the program.  That is something 
that could be provided in a portable way by the compiler.  Something 
like this:

struct FunctionInfo {
   char[] name;
     // name would include module name, and, for nested
     // or literal functions, the nested function name.
     // Something like:
     //    foo.bar.baz.MyFunc(int).nestedFunc1(char)
   char[] linkname;
     // this would be the C-compatible name, as it is
     // in the object file

   byte *startingAddr;
   size_t size;
   FunctionInfo[] subFunctions;
     // nested functions and literal functions go here
};

FunctionInfo[] GetAllFunctions() {...}
Jul 29 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Thu, 29 Jul 2004 21:48:00 -0700, Russ Lewis 
<spamhole-2001-07-16 deming-os.org> wrote:


 Sean Kelly wrote:

 In article <Xns9536AC639A46itsFarmer 63.105.9.61>, Farmer says...


 So you know where the exception was thrown and where it was caught, 
 but you don't known what happened in between.
 I for one, refused to use exceptions in C++ mainly for that reason. 
 And the one time, I did use exceptions, I actually hacked the 
 stacktrace in my code  by hand and a little help from the preprocessor.


 There have been articles written by very smart people on how to (in 
 code)
 generate stack traces in C++ when exceptions are thrown.  IIRC the 
 conclusion
 was that it's just not possible to do very well.  I agree that it would 
 be nice
 to have compiler support for stack traces when exceptions are thrown.


 It is possible to do a portable stack trace if you know the starting 
 address and size of every function in the program.  That is something 
 that could be provided in a portable way by the compiler.  Something 
 like this:

 struct FunctionInfo {
    char[] name;
      // name would include module name, and, for nested
      // or literal functions, the nested function name.
      // Something like:
      //    foo.bar.baz.MyFunc(int).nestedFunc1(char)
    char[] linkname;
      // this would be the C-compatible name, as it is
      // in the object file

    byte *startingAddr;
    size_t size;
    FunctionInfo[] subFunctions;
      // nested functions and literal functions go here
 };

 FunctionInfo[] GetAllFunctions() {...}


I think some little help by the compiler would go a long way to making a 
stack trace nice and easy to implement. Then someone could write one, put 
it in phobos, and I could use it (I dont need it right now, I just know I 
will need it when I write commercial server software in D)

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 29 2004
prev sibling parent Regan Heath <regan netwin.co.nz> writes:
On Wed, 28 Jul 2004 23:43:33 -0700, Walter <newshound digitalmars.com> 
wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsbvo8cpg5a2sq9 digitalmars.com...

 Cool. Is "access violation" == SIGSEGV

 Does it catch anything else as well? It would be cool if I could catch:

 #define SIGINT          2       /* interrupt */
 #define SIGILL          4       /* illegal instruction - invalid 
 function
 image */
 #define SIGFPE          8       /* floating point exception */
 #define SIGSEGV         11      /* segment violation */
 #define SIGTERM         15      /* Software termination signal from kill


 */

 #define SIGBREAK        21      /* Ctrl-Break sequence */
 #define SIGABRT         22      /* abnormal termination triggered by 
 abort
 call */

 (the above are just the windows signals)


 Yes. If you want to see how it's done, see internal\deh.c function
 _d_translate_se_to_d_exception()


 or the third option, my favourite:
   - The compiler defines a 'char[] file' and 'uint line' which I can


 access.

 Why is that so hard to do?


 I always thought __FILE__ and __LINE__ are just so ugly.


So change the names. debug.file and debug.line are fine by me.


 But when you think
 about it, __FILE__ and __LINE__ only really make sense for macros. Using
 them directly is pointless, isn't it?


No.


 Wouldn't it make sense to throw a
 string, and then grep on that string if you can't remember where it came
 from?


Then you have to make sure all your strings aren't the same, if the same 
problem is thrown from several locations "Out of memory" you want the same 
string.


 You can also simply write:
     assert(p != null);
 and not generate a seg fault.


Yeah, as long as I remember to check for them all time, I'd rather not 
have to, like you said why do this when the hardware will do it for me ;)

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 29 2004
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
I have written some code that allows you to view & dump the current 
stack.  My thought is that many exception types should, by default, 
perform this stack dump when they are created.  Then, whenever they are 
caught, the user can implement a stack backtrace.

We need to add these functions to class Thread:


class Thread {
...
     static byte[] ViewStack() {
       Thread t = <getCurrentThread>;
       return t.ViewStack();
     }

     byte[] ViewStack() {
       // swap the array indices for STACK_GROWS_UP
       assert(this.stackBottom > Thread.getESP());
       return (cast(byte*)0)[Thread.getESP()..this.stackBottom];
     }
...
}


I created this class.  Some types of exceptions probably should not do a 
stack dump; others (like SegFault and AssertError) should do so. 
Perhaps AssertError should be a child of a class something like this:


class Error_DumpsStack : Error {
   byte[] stackDump;
   this(char[] arg) {
     super(arg);
     stackDump = Thread.ViewStack().dup;
   }
}


Finally, users (or perhaps the standard D loader function?) should do 
this.  This code requires that somebody write a function 
PrintStackBackTrace(byte[]):


int main(char[] args) {
   try {
     ...put your main code here...
   }
   catch(Error_DumpsStack e) {
     PrintStackBacktrace(e.stackDump);
   }
   catch(Error e) {
     ...whatever...
   }
}
Jul 29 2004
next sibling parent Ant <duitoolkit yahoo.ca> writes:
On Thu, 29 Jul 2004 17:51:36 -0700, Russ Lewis wrote:


 I have written some code that allows you to view & dump the current 
 stack.


50 lines of code?
What are we waiting?

oh, right, it took 1 year to get listdir on linux version.

Walter, please, this should have been there since 0.01.

Ant
Jul 29 2004
prev sibling next sibling parent reply parabolis <parabolis softhome.net> writes:
Russ Lewis wrote:


 I have written some code that allows you to view & dump the current 
 stack.  My thought is that many exception types should, by default, 


Any chance you will post it?


 perform this stack dump when they are created.  Then, whenever they are 
 caught, the user can implement a stack backtrace.
 
 We need to add these functions to class Thread:


Why not add char[] stackDump to Exception and fill it in in the 
Exception construction? You should also be able to add a 
function printStackTrace() to Exception and all Errors will thus 
have the data by default.
Jul 29 2004
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
parabolis wrote:

 Russ Lewis wrote:
 

 I have written some code that allows you to view & dump the current 
 stack.  My thought is that many exception types should, by default, 


 
 Any chance you will post it?


Well, what I've posted already is the distilled core of the code.  I'll 
post the whole program at the bottom of this message.


 Why not add char[] stackDump to Exception and fill it in in the 
 Exception construction? You should also be able to add a function 
 printStackTrace() to Exception and all Errors will thus have the data by 
 default.


IMHO, you shouldn't have stack trace in every Exception because some are 
likely to be caught and handled...and then doing a stack trace would be 
wasteful.  Perhaps I am wrong, though.



Here's the complete program.  It compiles and (seems to) work on linux.


 import std.thread;
 import std.string;
  
 byte[] ViewStack(Thread t) {
   assert(t.stackBottom > Thread.getESP());
   return (cast(byte*)0)[Thread.getESP()..t.stackBottom];
 }
  
 byte[] ViewStack() {
   return ViewStack(Thread.getAll()[0]);
 }
  
 class Error_DumpsStack : Error {
   byte[] stackDump;
   this(char[] arg) {
     super(arg);
     stackDump = ViewStack().dup;
   }
 }
  
 int main() {
   byte[] stackView = ViewStack();
   byte[] stackCopy = stackView.dup;
   try {
     throw new Error_DumpsStack("test");
   }
   catch(Error_DumpsStack e) {
     printf("stackView = %d/%p stackCopy=%d/%p stackDump=%d,%p\n",
stackView,stackCopy,e.stackDump);
     printf("cmp(...) = %d\n",
cmp(cast(char[])stackView[stackView.length/2..stackView.length],cast(char[])e.stackDump[e.stackDump.length-stackView.length/2..e.stackDump.length]));
   }
  
   return 0;
 }
Jul 29 2004
next sibling parent Regan Heath <regan netwin.co.nz> writes:
On Thu, 29 Jul 2004 21:40:02 -0700, Russ Lewis 
<spamhole-2001-07-16 deming-os.org> wrote:


 parabolis wrote:

 Russ Lewis wrote:


 I have written some code that allows you to view & dump the current 
 stack.  My thought is that many exception types should, by default,


 Any chance you will post it?


 Well, what I've posted already is the distilled core of the code.  I'll 
 post the whole program at the bottom of this message.


 Why not add char[] stackDump to Exception and fill it in in the 
 Exception construction? You should also be able to add a function 
 printStackTrace() to Exception and all Errors will thus have the data 
 by default.	


 IMHO, you shouldn't have stack trace in every Exception because some are 
 likely to be caught and handled...and then doing a stack trace would be 
 wasteful.  Perhaps I am wrong, though.


I agree. If some sort of compiler support was added for this then the 
catch could indicate stack information was required eg.

try {
}
catch(Exception e, Stack[] s) {
}

or something similar.


 Here's the complete program.  It compiles and (seems to) work on linux.


 import std.thread;
 import std.string;
  byte[] ViewStack(Thread t) {
   assert(t.stackBottom > Thread.getESP());
   return (cast(byte*)0)[Thread.getESP()..t.stackBottom];
 }
  byte[] ViewStack() {
   return ViewStack(Thread.getAll()[0]);
 }
  class Error_DumpsStack : Error {
   byte[] stackDump;
   this(char[] arg) {
     super(arg);
     stackDump = ViewStack().dup;
   }
 }
  int main() {
   byte[] stackView = ViewStack();
   byte[] stackCopy = stackView.dup;
   try {
     throw new Error_DumpsStack("test");
   }
   catch(Error_DumpsStack e) {
     printf("stackView = %d/%p stackCopy=%d/%p stackDump=%d,%p\n", 
 stackView,stackCopy,e.stackDump);
     printf("cmp(...) = %d\n", 
 cmp(cast(char[])stackView[stackView.length/2..stackView.length],cast(char[])e.stackDump[e.stackDump.length-stackView.length/2..e.stackDump.length]));
   }
    return 0;
 }






-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 29 2004
prev sibling parent reply parabolis <parabolis softhome.net> writes:
Russ Lewis wrote:

 Why not add char[] stackDump to Exception and fill it in in the 
 Exception construction? You should also be able to add a function 
 printStackTrace() to Exception and all Errors will thus have the data 
 by default.


 
 
 IMHO, you shouldn't have stack trace in every Exception because some are 
 likely to be caught and handled...and then doing a stack trace would be 
 wasteful.  Perhaps I am wrong, though.


I can see your point. I am just not sure how one would catch an 
error thrown by, for example, source you do not control. Say 
std.utf's validate().

Also I was (and still do) think it might be possible without 
actually copying the entire stack itself. Provided that 
Exceptions chaining back through a program do not change ESP 
then it would be possible for my suggested printStackTrace() to 
simply start walking from ESP back to main().

However if ESP is changed while Exceptions propagate back then 
then your current implementation fails to display the part of 
the stack that actually caused the Error/Exception to be thrown. 
The only way to fix that is copy the entire stack for each new 
Error/Exception.
Jul 30 2004
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
parabolis wrote:

 I can see your point. I am just not sure how one would catch an error 
 thrown by, for example, source you do not control. Say std.utf's 
 validate().
 
 Also I was (and still do) think it might be possible without actually 
 copying the entire stack itself. Provided that Exceptions chaining back 
 through a program do not change ESP then it would be possible for my 
 suggested printStackTrace() to simply start walking from ESP back to 
 main().
 
 However if ESP is changed while Exceptions propagate back then then your 
 current implementation fails to display the part of the stack that 
 actually caused the Error/Exception to be thrown. The only way to fix 
 that is copy the entire stack for each new Error/Exception.


I'm pretty sure that 'esp' is the name of the Stack Pointer register in 
i386.  So yeah, getESP() will probably change as soon as you leave your 
current stack frame.

Come to think of it, I've seen it change when I just declare another 
local variable:

   uint a = Thread.getESP();
   uint b = Thread.getESP();
     // b will be a+4, IIRC

Plus, when you go back many stack frames to a catch() block and then run 
code there, you are overwriting old stack frames and a backtrace is 
impossible.

I'm starting to think that the "stackDump" variable should be added to 
Error itself, but only some types of Error would initialize it by 
default.  But you could add a stack dump at any time if you wanted:

   try {
     CallLibraryFunction();
   }
   catch(Error e) {
     if(e.stackDump.length == 0)
       e.DumpStack();
   }
Jul 30 2004
parent reply parabolis <parabolis softhome.net> writes:
Russ Lewis wrote:

 
 I'm pretty sure that 'esp' is the name of the Stack Pointer register in 
 i386.  So yeah, getESP() will probably change as soon as you leave your 
 current stack frame.


Yes ESP is the stack pointer and leaving the 'stack frame' means 
that you either called a function (call ???) or returned from a 
function (ret). The call instruction pushes the current IP onto 
the stack and ret results in a previously pushed IP being popped 
so ESP is pretty much guaranteed to change.

However from what I have seen D's 'stack frame' is nothing more 
than just the IP that is pushed during a call instruction.

(I am no expert an hope any real experts will point out any 
errors/over simplifications I made)


 
 Come to think of it, I've seen it change when I just declare another 
 local variable:
 
   uint a = Thread.getESP();
   uint b = Thread.getESP();
     // b will be a+4, IIRC


Usually local variables are stored on the stack and so 
allocating variables is done by moving ESP to account for the 
amount of variable you just allocated.

(Again - I am no expert an hope any real experts will point out 
any errors/over simplifications I made)


 
 Plus, when you go back many stack frames to a catch() block and then run 
 code there, you are overwriting old stack frames and a backtrace is 
 impossible.


I am not yet familiar enough with D's internals to know how the 
try/catch/finally semantics are actually implemented.


 
 I'm starting to think that the "stackDump" variable should be added to 
 Error itself, but only some types of Error would initialize it by 
 default.  But you could add a stack dump at any time if you wanted:
 
   try {
     CallLibraryFunction();
   }
   catch(Error e) {
     if(e.stackDump.length == 0)
       e.DumpStack();
   }
 


I was writing a (rather long) post to explain why I still think 
my suggestion of adding a printStackTrace() function to 
Exception (instead of Error as Error inherits from Exception) is 
what you want to do.

I would implement such a function by assuming the 
try/catch/finally implementation does not write to the stack on 
the way back towards main. If this is true then all you really 
need to know to implement printStackTrace() is what the value of 
ESP was when the Error/Exception was thrown. Then if a used 
wants a stack trace the printStackTrace() function will provide it.

It has only a cost of 4 bytes additional memory for 
Exception/Error classes and it is a simple mov instruction to 
initialise it in the constructor. So this method essentially 
takes absolutely no time or memory to implement.

Again any oversights or suggestions are requested.
Jul 30 2004
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
parabolis wrote:

 Russ Lewis wrote:
 

 I'm pretty sure that 'esp' is the name of the Stack Pointer register 
 in i386.  So yeah, getESP() will probably change as soon as you leave 
 your current stack frame.


 
 
 Yes ESP is the stack pointer and leaving the 'stack frame' means that 
 you either called a function (call ???) or returned from a function 
 (ret). The call instruction pushes the current IP onto the stack and ret 
 results in a previously pushed IP being popped so ESP is pretty much 
 guaranteed to change.
 
 However from what I have seen D's 'stack frame' is nothing more than 
 just the IP that is pushed during a call instruction.
 
 (I am no expert an hope any real experts will point out any errors/over 
 simplifications I made)
 

 Come to think of it, I've seen it change when I just declare another 
 local variable:

   uint a = Thread.getESP();
   uint b = Thread.getESP();
     // b will be a+4, IIRC


 
 
 Usually local variables are stored on the stack and so allocating 
 variables is done by moving ESP to account for the amount of variable 
 you just allocated.
 
 (Again - I am no expert an hope any real experts will point out any 
 errors/over simplifications I made)
 

 Plus, when you go back many stack frames to a catch() block and then 
 run code there, you are overwriting old stack frames and a backtrace 
 is impossible.


 
 
 I am not yet familiar enough with D's internals to know how the 
 try/catch/finally semantics are actually implemented.
 

 I'm starting to think that the "stackDump" variable should be added to 
 Error itself, but only some types of Error would initialize it by 
 default.  But you could add a stack dump at any time if you wanted:

   try {
     CallLibraryFunction();
   }
   catch(Error e) {
     if(e.stackDump.length == 0)
       e.DumpStack();
   }


 
 I was writing a (rather long) post to explain why I still think my 
 suggestion of adding a printStackTrace() function to Exception (instead 
 of Error as Error inherits from Exception) is what you want to do.
 
 I would implement such a function by assuming the try/catch/finally 
 implementation does not write to the stack on the way back towards main. 
 If this is true then all you really need to know to implement 
 printStackTrace() is what the value of ESP was when the Error/Exception 
 was thrown. Then if a used wants a stack trace the printStackTrace() 
 function will provide it.
 
 It has only a cost of 4 bytes additional memory for Exception/Error 
 classes and it is a simple mov instruction to initialise it in the 
 constructor. So this method essentially takes absolutely no time or 
 memory to implement.
 
 Again any oversights or suggestions are requested.


As soon as your catch block calls printStackTrace(), you are creating a 
new stack frame that overwrites the old call stack.  The moment you call 
printStackTrace, it becomes impossible to do a stack backtrace from the 
old ESP.
Jul 30 2004
parent reply parabolis <parabolis softhome.net> writes:
Russ Lewis wrote:


 
 As soon as your catch block calls printStackTrace(), you are creating a 
 new stack frame that overwrites the old call stack.  The moment you call 
 printStackTrace, it becomes impossible to do a stack backtrace from the 
 old ESP.
 


I am assuming the ESP is already corrupt by the time you would 
call printStackTrace(). Thus:
================================================================
     class Exception {
         uint esp_cache;

         this( char[] msg ) {
             asm { mov esp_cache, ESP; }
             esp_cache -= 2; // see note below
             // ...
         }
         void printStackTrace() { /* .... */ }

     class Error : Exception {
     }
================================================================
The "esp_cache -= 2" is assuming ESP reflects a value 8 bytes 
above the ESP before this object was created. The first is the 
return address and the second is the pointer passed to this().

Actually the esp_cache adjustment is more involved than just 
adjusting for the ESP change resulting from calling the 
constructor. You are going to have to walk back down the stack 
when subclasses are created and their constructors alter ESP 
before the Exception class constructor is called.

The code is just to illustrate roughly how the ESP is saved and 
how it would be accessed in printStackTrace().

Of course you will get strange results if you keep a reference 
to an Exception class and start using the stack again and then 
finally call printStackTrace(). Also you get strange results if 
you just create a new Exception to have it around and then call 
printStackTrace().

However it may be possible to change things around to alleviate 
the odd cases.
Jul 30 2004
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Assuming that the function "catcher" has the catch block which will 
catch a certain exception, the stack will look something like this:

foo
   bar
     baz
       fred
         catcher
         <try-block>
           wilma
             barney
               function_with_error
                 Error.this() <- ESP points here during
                                 Error constructor


Now, when the error gets thrown, then the stack looks like this:

foo
   bar
     baz
       fred
         catcher
         <catch-block>

If you then call ANY function or create ANY local variables, then it 
looks like this:

foo
   bar
     baz
       fred
         catcher
         <catch-block>
           printStackTrace()

Notice that printStackTrace() now resides at the same place (more or 
less) as where the wilma function used to be.  So printStackTrace() is 
overwriting the data from wilma!  printStackTrace() is, by its very 
nature, corrupting the very stack that it is trying to dump.

That's why, if you want to do a stack dump in a catch block, you MUST 
MUST MUST duplicate the stack data before actually throwing the 
exception.  Once you've thrown your way out of a function frame, you 
can't know whether ANY of that frame is still valid.
Jul 30 2004
parent reply parabolis <parabolis softhome.net> writes:
Russ Lewis wrote:

 If you then call ANY function or create ANY local variables, then it 
 looks like this:
 
 foo
   bar
     baz
       fred
         catcher
         <catch-block>
           printStackTrace()
 
 Notice that printStackTrace() now resides at the same place (more or 
 less) as where the wilma function used to be.  So printStackTrace() is 


Yes I see what you mean. However all is not lost:
================================================================
    r-type fred( params ... ) {
            // ...
         try {
             // ...
              wilma() // Exception thrown
             // ...
         } catch( Exception e ) { e.printStackTrace(); }
     }
================================================================
This is what I consider the general case. Should this happen 
then (not counting the constructor issue I mentioned before) the 
only *write* to the stack /should/ be "call printStackTrace" 
which as I have will only write the return address which will be 
in fred.

That means you can inspect all the stack variables in wilma and 
you can find that wilma called barney and again see all the 
stack variables in barney. The same goes with 
function_with_error. You can walk way up to the Exception 
constructor.

Furthermore you can walk down the stack back to main. Sadly the 
only thing you /cannont/ do is figure out which function wilma 
is which is a rather important piece of information.

I just found that part of the exception handling is done with 
src/phobos/internal/deh2.d which has some helpful looking 
structs in it.

Given that D's exception handler has already run when you call 
printStackTrace() and that you can walk back up to the handler's 
info you might be able to add something like an array of all the 
return addresses on the way back down to main. With that 
information you would be able to get the information that is 
overwritten by a call to printStackTrace() and have it work as 
expected.
Jul 30 2004
next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Fri, 30 Jul 2004 18:26:55 -0400, parabolis <parabolis softhome.net> 
wrote:

 Russ Lewis wrote:

 If you then call ANY function or create ANY local variables, then it 
 looks like this:

 foo
   bar
     baz
       fred
         catcher
         <catch-block>
           printStackTrace()

 Notice that printStackTrace() now resides at the same place (more or 
 less) as where the wilma function used to be.  So printStackTrace() is


 Yes I see what you mean. However all is not lost:
 ================================================================
     r-type fred( params ... ) {
             // ...
          try {
              // ...
               wilma() // Exception thrown
              // ...
          } catch( Exception e ) { e.printStackTrace(); }
      }
 ================================================================
 This is what I consider the general case.


I don't agree. I think the general case is more like:

void main() {
   try {
     ..entire program code goes in here..
   } catch (Exception e) {
     ..catches any/all exceptions that are not caught and handled inside 
the program code..
     e.printStackTrace();
   }
}


 Should this happen then (not counting the constructor issue I mentioned 
 before) the only *write* to the stack /should/ be "call printStackTrace" 
 which as I have will only write the return address which will be in fred.

 That means you can inspect all the stack variables in wilma and you can 
 find that wilma called barney and again see all the stack variables in 
 barney. The same goes with function_with_error. You can walk way up to 
 the Exception constructor.

 Furthermore you can walk down the stack back to main. Sadly the only 
 thing you /cannont/ do is figure out which function wilma is which is a 
 rather important piece of information.

 I just found that part of the exception handling is done with 
 src/phobos/internal/deh2.d which has some helpful looking structs in it.

 Given that D's exception handler has already run when you call 
 printStackTrace() and that you can walk back up to the handler's info 
 you might be able to add something like an array of all the return 
 addresses on the way back down to main. With that information you would 
 be able to get the information that is overwritten by a call to 
 printStackTrace() and have it work as expected.


Yes, I think actual compiler support can make this a trivial thing to 
implement. I was kinda hoping for the ability to say

catch (Exception e, Stack s) {
   ..use s to output the stack where e was thrown..
}

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 31 2004
parent parabolis <parabolis softhome.net> writes:
Regan Heath wrote:

 This is what I consider the general case.


 
 
 I don't agree. I think the general case is more like:
 
 void main() {
   try {
     ..entire program code goes in here..
   } catch (Exception e) {
     ..catches any/all exceptions that are not caught and handled inside 
 the program code..
     e.printStackTrace();
   }
 }


Sorry I should have been more clear. What I meant to get across 
with my general case example was that printStackTrace() would be 
immediately inside a catch block. Your example agrees with what 
I was assuming the general case would be. The case where 
printStackStrace() might have odd performance is a case in the 
stack is modified before calling printStackTrace().


 
 
 Yes, I think actual compiler support can make this a trivial thing to 
 implement. I was kinda hoping for the ability to say
 
 catch (Exception e, Stack s) {
   ..use s to output the stack where e was thrown..
 }
 


That is an interesting suggestion.
Aug 01 2004
prev sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <ceehvn$6qm$1 digitaldaemon.com>, parabolis says...


================================================================
This is what I consider the general case. Should this happen 
then (not counting the constructor issue I mentioned before) the 
only *write* to the stack /should/ be "call printStackTrace" 
which as I have will only write the return address which will be 
in fred.


I think you may be forgetting that an exception (in the X86 sense, not in the D
sense) could be thrown at any time. For example, an interrupt is a hardware
exception, and one of these will be thrown every few milliseconds to determine
whether or not a process-switch is required. When this happens, every register
(and a few other things besides) are backed up onto the stack. In general, an
(X86) exception handler can utilise arbitrary amounts of stack space.

In summary, everything beyond the top of the stack must always be assumed to be
corrupt.
Aug 01 2004
parent parabolis <parabolis softhome.net> writes:
Arcane Jill wrote:


 I think you may be forgetting that an exception (in the X86 sense, not in the D
 sense) could be thrown at any time. For example, an interrupt is a hardware
 exception, and one of these will be thrown every few milliseconds to determine
 whether or not a process-switch is required. When this happens, every register
 (and a few other things besides) are backed up onto the stack. In general, an
 (X86) exception handler can utilise arbitrary amounts of stack space.
 
 In summary, everything beyond the top of the stack must always be assumed to be
 corrupt.
 


I am not forgetting these process switches are thrown. I was 
(wrongly I take it) assuming that such contect switches would be 
handled by preallocating space at the bottom of the stack when a 
process is created explicitly for storing registers during 
context switches.

That is exacactly the sort of information I am most thankful to 
hear. I will have to look into this. Thanks!
Aug 01 2004
prev sibling parent reply parabolis <parabolis softhome.net> writes:
Russ Lewis wrote:

 
 We need to add these functions to class Thread:
 
 
 class Thread {
 ....
     static byte[] ViewStack() {
       Thread t = <getCurrentThread>;
       return t.ViewStack();
     }
 
     byte[] ViewStack() {
       // swap the array indices for STACK_GROWS_UP
       assert(this.stackBottom > Thread.getESP());
       return (cast(byte*)0)[Thread.getESP()..this.stackBottom];
     }
 ....
 }


That is pretty slick code... Treating all of memory as an array, 
slicing it and then duplicating. :)

However I do not understand why you need a reference to the 
current thread (or to change std.thread.d) to do this. Shouldn't 
you be able to get the current thread's ESP just by using:
================================================================
     byte[] ViewStack() {
         uint stack_top;
         asm { mov stack_top, ESP; }
         return (cast(byte*)0)[stack_top..this.stackBottom]
     }
================================================================
Jul 30 2004
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
parabolis wrote:

 That is pretty slick code... Treating all of memory as an array, slicing 
 it and then duplicating. :)


I was pretty proud of it when I stumbled upon it :)


 However I do not understand why you need a reference to the current 
 thread (or to change std.thread.d) to do this. Shouldn't you be able to 
 get the current thread's ESP just by using:
 ================================================================
     byte[] ViewStack() {
         uint stack_top;
         asm { mov stack_top, ESP; }
         return (cast(byte*)0)[stack_top..this.stackBottom]
     }
 ================================================================


When you dump your own stack, your code is probably far better.  But I 
have never taken the time to learn asm, so I use library functions instead.

Well, I do think that you should be able to dump the stack from other 
threads.  For instance, if you are about to die, you might want to do this:

   Thread.pauseAll();
   foreach(Thread t; Thread.getAll()) {
     printf("Stack backtrace of thread %p:\n", t);
     PrintStackBacktrace(t.ViewStack());
   }
   kill_program();
Jul 30 2004
parent parabolis <parabolis softhome.net> writes:
Russ Lewis wrote:


 
 When you dump your own stack, your code is probably far better.  But I 
 have never taken the time to learn asm, so I use library functions instead.


Yeah I kind of suspected you might not know asm. That is why I 
sent the code. Now your code can be fast too. :)


 
 Well, I do think that you should be able to dump the stack from other 
 threads.  For instance, if you are about to die, you might want to do this:
 
   Thread.pauseAll();
   foreach(Thread t; Thread.getAll()) {
     printf("Stack backtrace of thread %p:\n", t);
     PrintStackBacktrace(t.ViewStack());
   }
   kill_program();
 


Sute I can see why that might be useful. You should be 
/absolutely/ sure nothing you do after Threa.pauseAll that 
results in a synchronised block being excuted however.
Jul 30 2004