www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Stack Tracing

reply "Maxime Larose" <mlarose broadsoft.com> writes:
(Walter, I have some questions/comments for you down below.)

I finally implemented stack tracing for D.

Example
===========================
D:\trunk\src\test>stacktrace
Exception:"created exception"
  at .test.stacktrace.methodC (test\stacktrace.d:16)
  at .test.stacktrace.methodB (test\stacktrace.d:13)
  at .test.stacktrace.methodA (test\stacktrace.d:10)
  at main (test\stacktrace.d:7)
  at _main+008F
CustomException:"you idiot throwing exceptions around!"
  at .test.stacktrace.methodC (test\stacktrace.d:19)
  at .test.stacktrace.methodB (test\stacktrace.d:13)
  at .test.stacktrace.methodA (test\stacktrace.d:10)
  at main (test\stacktrace.d:7)
  at _main+008F
AccessViolationException:"Access Violation"
  at .test.stacktrace.methodB (test\stacktrace.d:13)
  at .test.stacktrace.methodA (test\stacktrace.d:10)
  at main (test\stacktrace.d:7)
  at _main+008F
DivisionByZeroException:"Integer Divide by Zero"
  at .test.stacktrace.methodC (test\stacktrace.d:32)
  at .test.stacktrace.methodB (test\stacktrace.d:13)
  at .test.stacktrace.methodA (test\stacktrace.d:10)
  at main (test\stacktrace.d:7)
  at _main+008F


Code that produces the above output
================================
module test.stacktrace;
class CustomException : Exception
{ this(char[] msg) { super(msg); }
}

void main() {
  methodA();
}
void methodA() {
  methodB();
}
void methodB() {
  methodC();
}
void methodC() {
  Exception e = new Exception("created exception");
  e.print();
  try {
    throw new CustomException("you idiot throwing exceptions around!");
  } catch (Exception e)    {
    e.print();
  }
  try {
    Object o;
    o.print(); // access violation
  } catch (Exception e) {
    // methodC may be missing from the output...
    e.print();
  }
  try {
    int divideByZero(int a) { return a/0; }
    int i = divideByZero(5);
  } catch (Exception e) {
    // methodC may be missing from the output...
    e.print();
  }
}

Notes
==================
Altough it does not currently work, the Exception could also be able
to contain a 'cause' (i.e. another exception). In this case, the stack trace
would contain the cause exception, as in:
Exception1:"message"
  ...
  ...
Caused by:
Exception2:"message"
  ...
  ...

This is all already coded, but DMD itself currently expects
Exception to have only one parameter... Walter could fix
this, I can't.

If you want to use stack tracing, you will have to recompile phobos.lib
for now. Hopefully, Walter can include it in the next release of DMD
so it will not have to be done manually anymore.
See below for instructions.


General Usage/Caveats:
==========================
- Only implemented on Windows x86 for now. However the framework is in place
  to support other platforms and only one method (per platform) needs to be
  implemented to do so (and some aliases defined). Unfortunately,
  it is that method that does pretty much all the work... :-/
  AMD64 and Itanium (with Windows) could be supported easily with minor mods
  if I only knew how to do a try-except with DMC...

- For best results compile with: -g -debug (and no -O or -inline).
  It will work with any flags though, as long as you include -g. (But
  obviously, some stack frames will be missing from the output.)
  You will need to link your application with dbghelp.lib.
  See below for more info.

- Some Exceptions (e.g. StreamError) do not generate a stack frame at
  construction (even in debug version). Consequently, the stack trace
  reported is erroneous by one method call. I.e. it is not the reported
  function that has the exception but a function called
  by the reported function. There is unfortunately not much that I can do,
  it's Walter who's pulling the strings here. I suppose in debug version
  all functions should properly generate stack frames.

- When in the MSVC 6.0 debugger, stack tracing doesn't work. I suppose
  it is because it is MSVC that starts the application and "owns" it.
  However, I'd be interested to know if this situation applies to all
  debuggers or only this one.
  The resulting stack trace I get is something like:
  AccessViolationException:"Access Violation"
    Stack symbol not found (err=487)
    Stack symbol not found (err=487)
    at ProcessIdToSessionId+017D



To use stack tracing
=======================
Find attached the new or modified files:
phobos/win32.mak
phobos/internal/deh.c
phobos/internal/object.d
phobos/std/c/windows/dbghelp.d
dm/lib/dbghelp.lib - given here for convenience, but it can be easily
                     reconstructed from lib/dbghelp.lib (from Windows
                     platform SDK) with coff2omf. (Be sure to "lib /convert"
                     it before with MS lib)

So, in a nutshell:
1. Unzip and place each file to the directory where it belongs
2. Edit the attached win32.mak (change tool paths), or modify your own
   according to instructions below.
3. Recompile phobos: make -f win32.mak
4. Copy dmd/src/phobos/phobos.lib to dmd/lib (you should make a backup
   of the old phobos.lib just in case)
5. Compile your app with -g and link with dbghelp.lib
   Example with Derek's build utility:
   build test\stacktrace.d -debug -g dbghelp.lib

How to modify win32.mak
---------------------------
Your win32.mak should be modified thus (or use the one attached and
modify the tool paths):
...
unittest.exe : unittest.d phobos.lib
 $(DMD) unittest -g -L+dbghelp
 sc unittest.obj -g dbghelp.lib

OBJS= dbghelp.obj ...
...
dbghelp.obj : std\c\windows\dbghelp.d
 $(DMD) -c $(DFLAGS) std\c\windows\dbghelp.d
...


Let me know if you have any problems!



Comments/possible TODOs for Walter/me/others (in that order ;)
including some questions for Walter:
===============================================
- I cannot presently test on other platforms, so it is possible the
  versioning has bugs (i.e. will not compile). I did my best to ensure it
was
  not so, sorry for any inconvenience.

- The Exception class seems to be tied-in to the DMD core. This causes
  a number of problems and my current hierarchy is probably less than
  optimal and/or doesn't work 100% like intended.
  Ex 1:
In Object.d:
  class Exception...
  ...
  this(char[] msg, Exception cause)  // new ctor with 'cause' param
  {
    this.msg = msg;
    this.cause = cause;
    stackTrace = new StackTrace();
  }
  ...

In unittest.d:
  ...
  catch (Exception e)
  {
    // new ctor not recognized by DMD
    throw new Exception("Unable to perform operation", e);
  }

  Compiler complains:
  unittest.d(75): constructor object.Exception.this (char[]) does not match
  argument types (char[27],Exception )
  unittest.d(75): Error: expected 1 arguments, not 2



  "Caused by: + stack trace" printout could not be tested.
  (The new "system" Exceptions (AccessViolationException,
  DivisionByZeroException, StackOverflowException) should be made visible
  to the outside world so they can be specifically caught.)

  Ex 2:
  In Exception.this(), I called another member function: fillStackTrace().
  This compiled fine, but generated an access violation at run-time.
  Stepping through the disassembly showed that the generated address for
  the call to fillStackTrace() was invalid. It seems that calling a member
  method from Exception.this() causes an access violation... In the end,
  I added another class altogether to take care of the stack trace (which
  I now believe to be a good thing.)

- In a number of methods, I use the trick "asm { nop; }" to force
  the compiler to generate stack frames. (I typically use this in Exception
  constructors to have a valid starting point for the stack trace.)
  Maybe there is a better way to do that. At any rate, I believe that
  in these places stack frames should be generated even in release
  version.

- Some Windows aliases in std.c.windows.dbghelp.d should probably go
elsewhere.
  I'm not too familiar with the grand scheme, so I simply put them there
  for now. Given instructions, I could place them in the right file(s)
myself.

- It would be good to move exception-related classes out of object.d
  and in their own file. I tried to some extend, but because Exception is
  so tied to the core (see above), this seemed perilous for me to attempt.
  Again, given instructions I could do it myself.

- It would probably be a good idea to make sure that in debug version all
  functions generate a stack frame.

- I don't know how to generate try-except block with DMC.
  This would help x86 stack traces and is necessary to generate stack traces
  for other architectures. For instance, other platform supporting Windows
  could be rapidly supported by doing some minor modifications.

- When an exception causes the program to exit, the main handler prefixes
  "Error: " to the message. This prefix should be removed (the stack trace
is
  clear enough.)

- IMO, either Error should be at the top of it's own hierarchy or it should
  be dropped, since Exception now has a cause (so the stack trace can be
  displayed as Exception1:... Caused by: Exception2... Caused by:
Exception3...)
  Note the "Caused by" couldn't be tested (see above).

- The library dbghelp.lib would pretty much have to be included by default
  from now on.

- At this point, there is not much more I can do myself, and I hope you will
  take the time to integrate stack tracing in the next release of DMD
  (knowing, if the mythos in this newsgroup is true, that you don't
  have much ;).  I implemented it for my own benefit but I hope it will
  also benefit others. Of course feel free to rearrange and rewrite
  portions you are uncomfortable with. My own knowledge of DMD internals
  is very limited and there are probably better ways to do things than
  the way I did.

  As far as redistribution is concerned, I don't care who uses/redistributes
  this. However, I did put my name in the file where I wrotea significant
  amount of new code: object.d. I would like my name to remain
  there (or in another file if you rearrange/rewrite). That's because
  I'm a vain person. ;)

Thanks,

Max






begin 666 stacktracing.zip


ME/-NJTELZ&[O;F_?N[=^\,!]\(#ULORZB"?3BK5"C^T]?OQX^^'N[B,VNF;]
M>!)70<)>!D7988O%8B<2(S,8V FS&:X_2!)VANM+=L9+7ESR"(??%'%5\12W
M>1,D%2_8(9WBXN3 *N1Y%6<IFP9IE,3IA)7S/,\*F/XB3L-D'G'G:5E%<;8S
M?58;* "X/A:4<&K5A(-=1SCF/FBS_34_[$V</GJX=EI!M1\ 5F/FOSD^>?30
M_<PZAU^%>>/H19Q&V:(49S_0X_?>E>&[L C?R8%W? I7WIG>0PS;;7949+,:


MF/&.Z^ $:_>RM.)7E5HA1_MQF0=5"-!RWG6\KDMS&JM)DHT`K7F*U&F)=6/:
M>QDS+O:'/;Z(^#A..3,PKTZ !WW&OF$,Q. H"2:LRACL&8=!Q1DPJ9IR5EZ7
M%9^QN&3B0! 9UP7$>)&R_AL\1!$(;EEU!0.(N(:/]TC&D3UR82\!03M.QQGS


MY ?;X?MY4(+H`5]SO_):7I<1C\;S-"1-SS. `UF,4Q;,1C&'13,^RT"L9UG$
M$[(+%\"\)+C.YA7+QJS?%$3D*/$7O\=9P7KW[[LNV(1Y6"U#NS]IF6;MO."7
M7<=QX!"%"  .CL;9O&1<&R24"&N=U*!N<V4!.*)H(A:\;LUX0>N%H"%*W <9

M%Y0">7/D"][0/E[?F! 36!#P/"WC2<HC%L;9>%SR2L"+;[QQOX=*3D(6!57 
MQFBP .0%\4ILU_I\?Y>4L+C>#A'<LT )JAPDR;4?`KN7Z"DG&4[B[_R*A_.*
MNXZXO[VQ!/7H]NB HJ `U2*)D42X$)<K68[.(4*9&QR\Q7W]R">[(VG>\I8(
M2&MKLC/.JV)9=O35E837R<C+? 4=`7QP?BIH![RL+REXM6))G<Y:G5 &>34'
M!4:2T48K)*$N6WOONS61(8X> L?X(.]K[$ ;E5M*+$(Q_+V.[JAV02&9ZI)B




MOSPX U\,?HZS"M]'G:_Z7W7V8)LAN0[6!MVJBB MP<-QO^1^E<$(-]YCV=.K
M.;]0+K\>-D0RG)%QPRI-U2;:)Q/48>O< 0HXR"R6598+LPAGNN -*0BX[<=E
M;?)1M).2WXZVSH!J`K*GQ42 5=. `MB2C3C$PP6? (?A!43)L!D8)G1HPW-F
M!20[.'.<YO/J"7XY8+H<A%+Z(FPMGE(I7%P*4M>$A V3YSHH]K=SHR,`;Z.G

MXPHH\!"MYC6VG^FP!>/%DFTMQ9/"2PF4Z <-$?"2X?]$8^F=A-D07 -^2]*K
MGZ:X- 13BM_V'H < M_0GSPIN3P>[<S?Y[,<K8AE8?!6,_P5TR0TC'AR-D\C
MUW50EM/HJD-N'C_BKNNL\ /M?&I/&5_>SL.E"6$%868$,ZM,ZK)%Y:62917 


MDK6 KH BL6_[F1W0(>G9Y_O 4O&YSQ0?/-?Y2: `T!W&MVJRL/VLYI8!'ARS
M );K<:MIO/W,"M\$`$HXS: PS1/C<)H=)P8-%]M*=8 %"YR<B-Y:(0U>JQ5.
M P(^:ABS^ZQ^*J#C*(% 9$.8U ("<T0X/&2WRV+VU  /B^_?1Q008;IQ.$+Z
MT :VWXW?HW#H.W\>QI[\%5<ZE"R R<5X<38O*Z$BQ$GEA+3;!?A;+$,/MX%4

M[7;+4H\V,....]W 'V11[&VWEA-62<H;F\1 ON)R%)0\&[?"N(.<`7&'L,_3



MS"65'^(\%YE._5*;.24T6>*<93-GF;4N\1_,<5! C"LR/SQ.V5F)Z0HOML/Z
M&9B*-*MDWK)3TR63?I(- .Q)JP;6$^1P`*F>0).$6X\AHT79 =B%2F^IEMH1


M1AWTE\P=+0.85G$ZY^<\*,(II(F;!\2FF#N.J="+FC4OL; `81OD;#L[OM1H



M:QE/9DRB CT+XI*;DN M#K,C)-$PZV1X JG"\<FK \,7`SF]UV$M4?%J>X34
M'> E"P:!G6L+R G"6<EI2*!^D]6M6DB*$23&/[-RHDAJ!!S%1"8D\(56QYKS

ME6EAL4<57IT3T66DZ8+9[6<PD$ RNH\9&'P00-?,P03\*=.4SVH60TN<1[2X


MZS7Q11/Z?' &>+\^[ _\PW_XWP_.AD]6(/(11=K:\.&BP^X=0T0T`5^!$,#N
MT35#B



MKRI?JL-:(/+I!5I3:]JT0KNZ6&B5M>S99F4+YW _9==!ELXAJI[G("MESD-(
M(9<?\$QP'65S3!!(> Q<N6.*DLJOYO-RZD0+L,<,0ZCMO:6A73DB,XV53_7T
MUD!5><KEEIG0W'1</K$?LUW*(H[.:X,=R"IL =3%F54UK5A4M-C6EO TC,"Y

M8+;$ G(Y(=9[!60,P3R )L60II<L$PHD% <6%QSMY"7%')"1[;ABL0Q(97I'
MQ02[CF 7N.E(F8<N7:TK]Q,9I"26X.+ $'-!D0F^[>A=S/2I:Q)%C0B,80X 
M5^=9+ '%U]O5^5Y-4 &P(2&N`P=3\KGW4"Z[0V0G. E D<!$EQ2 BSX,817P

MON+\S%<7Q]R.7\55RT2ZR^9IW=.)&?SE"AO:V1GBYT669!.9$U]U)&6N.VPI

M'F]X\Y4WD\LWNME*RLFOODW#AMRL
MM86LT4[UR5U4Z]N!=(EU79.)/B20'35VE\MD'A01+"ZY:7;Y'V\PZ `QT*A(
M?P%9(9_ZL#A"]/^K.HO,&[!T/_(1.(IG/%4>?T4;V_\[DG['CJ2AC3&$-A-=
M:3+1C>(YO8WKRS",2XPB:/8<`?C/$^*/)HBBWP/-'9^:ZXGGK)6: "\U M?X
M51/B&#O/*UX2,:3Y;=X"1(HB"T*U>QL4N(NN](L`-P/25)QB5#A>!=CB$X><
M:5+)7S?VO':(^AP2$LL04S*$N7^)]:= W[.#L.-X,I?O<8MI;+,UEJLH'#T3


M=I_A)TJ69])3:1EQIB:U)MVRH*BK!;E_&_L-QS'30U\5J3TL7TRY">0J<*[\
M_JH4&6LMV<#C

M>TS] &(*$6< /,(&)PD^_,2IU8MUR NLIK,R "#S6G064
M*\."+^#H.6!L60 VS7(^GE-I L-^'-_/HPSB-?B, EDPX3M"8.$.3_?%G3U=
MP!!EBG*:S9.(3?!M$(VK;%ZZ1.:6`M8ZTBJ=&F8UR-,20G)?/7=CGT0MNY*L

M1<MQ\X]W\-DQG6B'4(?J&=Q$!D(6/$6-C0T4E-HB5O\PH3X$85Y7]QK*+]T2
M8F3-$+&IT&*FLZ6TU]H>>[O$M-=\&H.YU>JI?IKO!/66-0L/\E'*TFLDQ"ED


MJ%8&RV4NFT7(Z/VK+W>_AJ3?7%*-$*KP"WQJ1/;E_ TQZYC5'5K6T2OP7X[)
MY-YBRY'D<Z'^[0UJM+H%EMI7, P$?YE$) >RE$3T26WOF3%19$>%,EV0J$BB
M`=*(Q*9=HM00:<L/BN$2T=FS?5MX9-NF:A5EC1^%=VS+X._78OLG[ZI=VUPM
M3*?5':L>I/Y0G;CK6\!%;=CNDEG5K#K5


MSW9>S P1``!_6 ``"0```'=I;C,R+FUA:ZU<;6_<N!'^[ 7V/PA(/IS;>GM-

M(3DDY1F_2CZF7]B>YRQIRF37\CQ+KI*J+1I^9$G.=U5:O22GQW)7UBMX3?9E

MU_!\)LK%S[.[%-I(ZT04)&W!FX;5C4& 1B7XG=3-+Y0XFK.TD) KEK-&,!6,

M_\CKI&(YAQ;+(OEP\VYU_>MU\H_5]]\G8+(<5*C^(ED^DG]=R[H?5M__S=:M
MEHOE8O/+)3V)AU>;GSZ0]W>7%\<BN? QN:B 3I<<$E2X7%SIXI_A';J?UBRY

M_ N=/'O]W69SGES0!!XD_7GR^D\*<CJ- S(' 18TYLK'I/6Q3R2K&C6#DK4=
MK^1 ZZ;=";P`V&*'4+/OS TPT"B$JU5% L049YZ*RG '"P0A`Q0R>$(:*5LI

M\K!<9.Q10DR]>(;B1/V7UC6K8.I5925K:EB]5 G0\GC*V;-\%E9.F]H(G]&*
M-YRFN2R _QE5>AQ+T$I3I565OM!45?#B:UKQM& L179,>?%&$;1-N3^R8UF]
M*,F4J)\95S_)Z92K*K&<G1: (;QKS5_JAAVU%EF;,PZJJ-?L!_ES!POCQ[\[
MZ50;#R2=`4YIH[I?-Q4O#HJ '6NFN4RU8 "]=^U^KQ6 S<M)Z5:Q`WM6EJY 


M5WW7/M:8A$.'7_0+S9$=2OI%6U<](L/D99J9\6TR6/UJ$I354<\K*.6EI3JQ
M2JE8GEA1J7[".C'F%_06V_ M295QX.E GC;F >NY"H_T,:VPW),M )<6`>M'
M,R*BPKUIN=V+'AQ1BU_RLK *M/CEU' -[\$>EC\KVUUN*<!DN:V!3>! )H(6

MZP#QU27
M98;=OUI\F76TF?71[)FR4\/+8I5IINW=_=6EF/D/<LEEZA$6G7H22Z)H](M<
MRNI1+%_]! LXTSXH>P#GHHJE;S,<TOFIEY,KE^[%B2J7IZJD:S*-:K^LR91G
MUHTXW^QXG"-UFKS1S]IUZ0IPY>I).W/' 7<RIZQR >H=;S.:[JBU-B1 ..AX
MS8U)E O6W;!.VG;+M&;$M>-7]=KU6X,*GZ8-JAVCQDEOZ$BT/]1RV".J(NT3
M[6 +KZB'0/E%1"6]HVY4^$9M".4=]60`_XAGUG:CYA;MJ$D%FYMO]$'<#G"=

MTF$%9'1Y2$2ZHX"(+ ^)"&?>E]CQ(:V4C^I+:&<5%I*>*R!CMH2P%!T0X[H\


M:>N&;F[OE1\"T[*J2'/M\T'0EIA;$45%YC)$$T_X*'<YN,TZ:)KG)4TQ7YYK

M*?&[\Z9+0\T&;TO$K03W`[;MU2-21=T`.S3V(.6W[A$W54K%-#O
MR>D[V8.]GKC98ZKL'<G?)!T'M5!SP\LZY50>`]S6B/#R2A*J,]?U3JL?;F[_


M3!2+ TNO! X=XD-;4+'ASNQ2&*,>U[>VX7F <=F37C'0A%MFSZEP*$$)::M>

MYT8&-XR0J3>/:7% '\I#F

M?[C[^:?[2V2+NLGK<M^8G]NBS?/ML6U <WP,P.">\0S/6W6UW*94WBTBR&"=
M<)E `F]PDLI&FF+%5UZ5Q9$5S59NEN+$$1/8 T\15^TTCVJVI6U5"=(,SL>T
M$??)&#KG1S&4LPBW-85;6EQ9\9L->;7>PB8WUL(>S"4DMC7[K64%C7,?\G(7
M1ZJ!B(U1VI1'3JU-P^J9R4,I34_;`Z51%!R>ODRPC/ID,&4NGG Q`:8OPA$D

M*_,TYS6KXC.% Y=*Q1EW?#IEQ_!TLAWN+2#C[CY=;S[<86<G/]*H?[?V\];C

MZ9D\".HN\Y#V6W
MVHH$C32CCIN#U
M[?7GT*$$+?&M^'Z]U=^70^Z %^(+*VS"95$PN5=%8=/V78>>XE4-NF9I11_K
M$Z-3\?6 6Y_B?-7W"/"F6_$]/=94G*9MRIB%I[GE>6<!\;$G- `6!T</`2M&

M,648:BZNN5M[HY^$UK^&BB._L4GMCUX[.LBF_,(*<1R) L4N->'X_8<>Y">X
MM.GG^-G7LJGGT]]]-=!8N<[%KS'5"3:*G6;)6>?G:?Y; _5%X9'!2HLO[^FG
M<_]JX1U0NYO?[,-6Y*AY7335RT_!`9I_7(L=1<7^LLU"![E/XM^?H!-WTB>-

M(9E,_(<<P<=/^L-WMDGWB$E:QBCB-\/1B^ND:]SH_3)^]9ITQ9APBQDSY^0K
M7O0ROF].L;I) S;A:C9ZG:W*LJE'6QK]\*!H!BTWX6XF-B 4J[I.7G\G0DW/
MDZ.-M\0?DK/C 4J (G/?X469:,0U.7#A.Q/("YI<G-Z^P5&R$]L5;83ODB&5

MM%[//=)O2JK/Z>S4I003V$Z*=Q/#N^[\>GD9#OWN

M]H=PP(4#Q


MZ2,B'28SQF-ARP7*S$ \)D!IC,CAE*NN&^>&-">*=QU \Q  W,D=T10X#C=&


M="D;:R]6.29M(<+-(ED1S!"14]7+!4H>67N1TQ%9!P'_9')]UB \/B)K`$KR
M34=T>%_Q$""LTY76+N)]P K0.! _=D;)!+G'6C^ZD>HD3ZU[4?LQ' \&GL;S

MZN3/J=/8G#K9.65SF
M+H+$Y7M4VB"$L$VG,](JS2(J;B"P<[H$LS5*JHC*VR2,BW+OY!T;RE'#G"91
M8Y399G18?L<H6[%Y;6N;U%/&>0U""'>5FZ"6A4AYD_IHY64Z4%Q>0\Q1Q:0S

MA'6^S:"DS<<Q:99:K!H1JXQ8 ]V$3/J*B37:2;CT325H0G\')77N&<Q?*RIX

MNR93==W)?XH=`A%($;*&HD?%O4'#Y







MS#DO$'Q (+%- LS;)8B_39#H?DEF;IBDLV.2*/E,[ YUY%1"9AU+B'<N(1':
M6:P>:6SC)/-V3N)OG23&/(_8YXTY,S+/F1'?F9&HNR$SW0WINIO(QD%F;1S$
MVSA(=.< ,[<.TMD[2-S#D[DNGG1]/(EMU&3>3DW\K9K$+C1DWHV&^%<:$KO3
MD'F7&N+?:H:VD>F[B-M$(DK.4M%3<- 1S?%#U W]GAB<;_P$:KB(%9=4HF*'
M<DY943.94/[ZN[M/FW,9(B0?18[]>6(?MQOS<G]CGFYN[S'B\\UM1UXFZ!O(
M]?T&/3H^D4EOGM]OSD$>#JLFN


MF'40JU9KHP,1GRS[L&V?ZT%_'/6 8E6%<.Y3F0>72Z^+=R%G/2W4V SPVZ^=


M`+(9```)````9&)G:&5L<"YDM5GI;]LV%/^\`/D?^*UQ8#CM& 3#A&'P(2=&


M>> BS!BA_.)]S_CAAZLKI"^ . J/\L;Y67!(8LIK\O1O*2^AP1/F!$FV)6KX


M<#B8
MPUMS,YW-S<UB.+Z;+<W-[.-/-^ 7]/[E_8=KUP"O7Z%9Q$F(8'^ (J3"P3A-
M78XVDL?=?+VQ/R]&J_G-M8JP- .U+SOX1E:^+5D8I7V0Q A'/$8,*&+_HL&]
M5V(.LMK6T/,H8<RH[P/SIX#R%(<(*Q)P ANFGL1"&*(M9B0[^CX;&C*4&,)X
M< "P>](,%/N('0_;..PC%T=H2] W0N/7)4Q#O&N:(24$D1\CO(U3<!9 6K%G
M?? >D1O KJG"-_D.4Q;X98D/9$ZB'=\;%4$'_!(<TD/-$!0!.2B!WHE[[Y0$
M ;X.`4B0=3BKS/$B2B$.D `.0:3\QRE$1P;]KP+8+:!#C2WC%#T\B+8+X J)
MP-SA9&*9MKU9K"9F!FB%K$7LD0\W'V[ZS<V//S8V+8+#QB;$E6N+RB^)XYT6
M6SRB.M)7O \/Q, .JS&UR>Y HN*T8 02DHVZ(RLR4?[1Z""Y1/-UF4AGYBOU
M$])KP+0Y*05\9 \,` E8D;ATAN/[J35<F 5=7]_&D2>NI S((0-PBET!9AJG

M'CP]-TX"$+ ]2GTTO4>VZ6Y'J.;BT_  CR>CV_O)YM9T-I],RYZMEE+)Q^',
MV8 ECKD!S"]O392 .,+9(/-&Q2M+\HSN)W?F?%WRC1]3!"[?!E %CXP3>&%I
M(HKBH-.7"24^H50Y,P*F+OAC4(C*<*1DE3&DSO5[RW(?/&9MO?(ABK>_$Y?W


M3JO*A#X


M;)E,+!SM" ";\A+WG, BH A$ZK>?ONCC<DG(TP?*/ADMIU! 2\>-0E;D^7(>
M*I4:Z=;UN-X3 -V0>W8`"LANJ0!%UUV+0%Z,:LTCE9MU/]6O2LP9-;$5U';=
M5+FB=E,^X-=NZK=;O:E3A$X,-0[K3ZM95MRG "]'O!\SXO1H%!Q*22CQ,,=7
M?A(C*"W+A_F\K8-88S"3_7;]I6Y$$C,6  "$Z2X5703+$EL=VZ/5:IY=G&+:
MWI\^KAZ1CZE\E&T7/ZE&W&A<A#K

M4DS:./P>'><P2"S3PY;4X UL0CA"D3R3%2<(\Z2[/C$23(&N;2H03U$,`8)/

M:JS6SF9B3DW+,B>;^6HXL=6XK=9UOT(HSB7',M&']_W2]*"B9A\/-N&K1'Z9
M<9'OZ8V>U%V]/]B=B2\]P))OY ):N,G<1/LUC5WP8%]_3X!$J;()INY^C?F^
MK^[ZL^ )>T33]O*\KYRB2'2RN,C"5A=0#V>8C&#JU 'L5Q$-9ZD/+6_U$HK$

MQ+[9!IG?,2-:WO1A.79 5M XP]'<W S'4G"[Q(Q%WLJ\2:BN<2!3C" PYCV 
MO-'0-O\S:=F^ZN!+3B_J6YB(<JOU<*SATIZ+Z2 ;/NN:2)C(.OJ(PZ\WU[D*
M]74J':FUP.X>7K)S3 HXU)<VX,1JV/P/6-3<4U_5NM%&(1TB^Y).)J>RO%KC


M/5FHG)SM`J.*406+)H<_G 6/(OVJ%R49"'UH?!#G^<MJ V\-\VVU54G1!.L6


M7PL````T```+````9&)G:&5L<"YL:6+M6UEL7%<9_J]ILS6[LSAQTSII2(32

M14B `"GB 46J^D E*#Q4/*!*51$2$HM:D'BA2)SEWGO^<\Y_QN&1Q9+CF?/_


M$E9N5.<6H/N0!&TL9R,(J;F,ITI\7)FOU5D;X=,1`Y]QF? U<$_4"%O0'938

MZR.^87TD5>O#Y5<7M?SJ(I;/*;;\];"63^(BJ_-7'DH7.!THG,Z .8NSPIT!

M(IM;6IALSD=Q(TPX!KH?DH\;*)/D0CX)'GCZK,XNV'&M6625* X35EIIS$7U


M1CTJ5#LB)6PMXU$DP^1V]]MVV,HY2BPIL3"N+%X)$[[;AZ7,_K)-T3/H I3H
MS [8KDA7PI U$[X3J]&GH3NB)]"BZ9U$`6V%.UM DV*[W!+[C!NEA_4$Z&$M

M;RL;PVC%+'Y3X<X!&.+TJVRAUDY8/+[4K(CW&FLF\<IH6*_/<2,.W9)\Q,'R
M:ISHJ:M+E8IT#L*!U3C%KIR5&AQ:50.Q5_.S?C>2Z?7+4'H*SD %=I<)(GIK

M- (IG)YG21WG[EA9F1-2XHZR34%:NBBUWLJ^3N56;6P9NL>U><"$PHD1;& -
M3*9B>AZFD+5&YT$/(R]K\5OGP=9/K RI'U^3X=.T?FA;I?H)=UD+Z[5;IGYZ
MV#JOB-_23ZWO19
M`VLC[?.DWI]S\7^OQ.RF85_UL/8$%KLM3ZV/9A#K<\R8 )Q ^F<#HOTSUN^2
MM*>.?F*8TN^2:TY-_00#J9\B4/JE$#M^4$2]/"A^,$E6_&#AB/A!V3N33^B,

M X)FQD4I^Y?O-RK>T,.%8]9^\\4;^?PJTR/.]ZP]OXCD[ ^,ZS6_B,^=7X.(


M>"4E*0/LZF=:8!O UR\SP*Y^M 5V0?;Z")+//V(:\KL4TEX?GL^Z7$+G+)^E
MJ. 9-%K[#T=_98!I_2T+3"%7U3\SP+3^C 6FT5K_W/Y8^91I?\Q\RO%/_H1*
MU$>$]4^S YEPKL[.5RJLS0WS1W1 3M#UWO$)(,HCT-D+`S2[F+-1^<3[/4\T
MSKY?BIDOJOQ>3.U,=(,UC?P^'T7K87*[^?TFN,^(1#X Q6TIE\ 8Q. EYT/+

M&E)[UMCO#A77GTBTWN]J/SH<8G=D]3J:CF;))X&JUZGS97,;Y\LF6O[=P1+Y
MKLUCY;LN&;V-!Y_:9TM_Y0L]^J=$RSXXV%[ZISP^_7,R>H8'G^JOSJ> BS2J
M;9S/?-0ZGYK;/9]:WW2JQJ-8G2Q+7Y-,S+>%-_PUHAOY)QJW\D^,P/FGJE^F
M5*-^F8XAS3!G5K]4_DV.1DMQA8VKFP7DWRR:Y9]MI.W?]/H(%^6NCQQ%E0"3
MVUT?E1\669UEF]FH+V""55\P,'E]0<W?:)V%S:46= ])49O*>DQ7%S%CCE?O

M6>X/]""28?!Z_8',P69BQOA>%JN,_(%-,O(C!T?X`RY_NM:L%9<:K=FXEC#Q
M0<MW2&A-"1PAG_N#C.\J"ZOB;RF)6=C0_H"F8W_ D>#Q!]/4[4UF3PDB] <4
MUK"G^V!P.KS!2DNQCLB$KQU;KK43?KPFY',>*/= TCNZIRB5#W)_/=D(%]AB
MO76^5;O.8G&!)8J.9],7HJCZ"308[5=N?UP6?3_ATG1F3P&=^PE^/B7;U9OA
M3'0]U.<3CZ(5,+G=\\GWJ^8HL8I:W5-874S"Y\'%$?MU"VR2?)>2";[96*SK

MF'SZ/O_3T<KTD(/VTP-PORBIUAJLG82-%K<\HJ[,JE.UN3 4B<]'TQ?NQ:5G
MM[<P.K[503"N>67Q+45%5HU&Z_B6QP]V<)[%#U9DKGV.C<#Q`X]W!'5LF566
M$I$'R5D6.R.+=T RCG=HO(XO";JVAP01QY<4UK"'J?S<:(K7%-IC^181UR\I
MK%U_=7CT>7=(^+R[.+H^F/<%8 .8W7<21&T!2:B9OW+_EP?/:O/F(7[F_V Z

MA0E6;XUR'Y^P:VT6RR!#SQ=-Q_/ED>#I]R"Y]?DCR3 _HO'J8>_^PGW'__B?
M3V8?#NZ%1Y<!+ /4Q-=^.7BV^"3J`0O [<68!+*7XA)UQ?03<*\6W *R%KHK


M.-6+)[VY^ M$+OU5.AE^*3 3R>\$= )W)_!%];\)5 L4_Q:L%EGU]?E#BIU]
M/H>]/]WWIV#ZD#CG
M..X`W5^X#WIU[AT&7ZO1IX#J%/ F^.[Z;X-[5?]=\%ZLON&[$QGL<1=PU%_(
M/Q'XZ^]G`KOL/!7TJ([.D36J9\G(<VN?-[0;[.OI_\^N8N"^QG]OP^OPZO/\


M6G;XE2^C?S/XM\P_7QUH`XRF7T>X.9[B?QG_W<]_CW2\7:PG 6 <>I%J??DA

MY\^(07[F_SQ='7SUE^)+_YWWC([XK8!;OA\"JA'Y+'B:B<_9O<!C0'4"/ UT

M7^Q927UEM2+//X(>>=6XL^^?XR% >>'J+8 )^#S/`^3 :6CQ?P<`OI']-X7=
MG [GTMWUXO*DHN==<H&X![[HOS1;"LQ[A6\%=EG^^X%3E_P=4?K[BZ_T<+C/

M+F3E.VMSVSB2GS=5^0^(JB:A;(TL>SVI66N]58ZE)*[SJVQGD[M,2D6)D,0-
M17#YL


M4IEE0J4B7"11* -&`ZM3/\Y777$2BU )>2OC'%9&D<CG4O %H$ S,99B+J- 
M1*$_CJ28`AK$&O +?R8S1N6G81;&,S%-U8(6%YD4: H?+4J[U0DN9;H(LRQ4
M,9(_0S* ^EPA9A5+_(08:LO+G9,B350F.XPJC"=1$>#FP,&%3"<AL-A/X)P3
M/X<- -5^S+B)F6%.WU,9A%F>AN,B!Q;FC&N:2AFM.H!3C%4^AZV+="()?AS&


MS!I/2V1 D8]J%!23'!DF_,GG6"TC&<P6J!4PCZ UA C4I,!QXK!8J +T8UQA
M`_:G$ 2!0 4&HXSQ9*G\9Q$"X[LE0XY0) "D&7TK4]2)C \+C$C C'&T$F A
MGP',!\J+R9PENL:0-<8A_%BB:KC98LF%*0R!AH6_,F)(Y4+=`AK4.TTH*3 J
M(5-<[ETJ$Y!/>'>>/L&_!? +C$:1OO1Q1-X!IA =P],G7XCS.; 5_C_U)G,_
M%5L=T>UVVP`K].Q"+B:+Q+M588"SYCT+_U>.< 3\RGOY8*%P8%#PL5(1;:89



M3 5\3>*#B0.?WARS5BQ5^AF^=T0L99"A;P`5FH9WY&X-*1,_RSW<K$V?6)9M
MQ-ZD" E2R3$(GGDFU'>GRT66^-$]I]ST#O]9^%'F)-D2!CH$"P'A`/M!SW("
MAIM._4FE:\<HN!,0G"A%V+>T9PN$?YN/(\M U'2:R;Q/A F,XJ]X\!*Y>(%D

M=1X-=!NF.?!43(N80HI(5(C'$#F
MWM:$E]Q"6(?(W-;B-*9'MC*-_)G9`: 4NP?"\/OD78RQ(Z[OY$.,A(A,6Q&+
MP<AO?0R^BT2EX$?RH)N1"?<K`=RL$HFDEVQWV2D/SF&HS\H(05KZD[E ASKI
MNQR 7BQHG3CDMRWQ%[$-"RQUU6B_P33UPNH\7?3>#A(Z0C6)^F:CVMDJ>03 
MH'LQ"%Y /H'Y6"1S2H P! <%IT0P/8'X+N\ 8A&B+8CUJ0)F#TY/7V1=3%)2

MNN:9S$GFK$U)&Z2^YE&3/BXR;)/,-+U U\3-9,]:F^PB`<E>;2$?6MZ_LE=;

MB;QO."9$#J ><8:FMMK);OMC^*EOYAUS:ROV[EFQIU=PW/]:]^1UTQWAAT!.


MI:IK'+?+S6T6J&/;W?5]=_LVP-XZP)ZV#T
MV7,2>H_6_(&4ZKW(Y'EWB*Q7<N:G 8 +*-'!1X.?9G</_T5+?V6JG5:$Y3Y4


MA#F#K
M7T2<+]70 WX=05F;IBM.AOQH!B5S/E]T+8CK.=7ZW$B NC;FM PG.ID-2>5)
M*J,0%%1Q]P`J$JRLH:A&0K FSLP2"G%<3 HKTMWA4!7MF,V4L.ELC6VGP,AD
MO \4D-O;=76TM<Z9S]7=SUYIU+NE;,D>M6A1F"9Y*.FJ3 7%P;8$0.!?GC6 
M>G6H.Y/BU8! U.5X&0UL8?].1A-NW5- M!WFLNWS[C/0A -T\.H/=U\)N:_$

MR-2<).JMMO%*5JE=A^ 8.*.XCX$$GE<]+/S;V:I<]_!N(A,J>QL5./X;O+^X
M& A_S#RI'6Z1S<JC8-WA5>,5F\KNV/LP#M0R:XLR'ACDH.C^(ONX6R7">J2'
MZ2^Y' )L/S=DX*N$U3X8Y Y_"%H=I!6%C 4SOJ[\,)/E$;W>74_V]O=[O1YH


M&*1IT% )\<Y.U;CE$ V\&$.CAS/]WH?^=G9(^M8#H D](/J)AH_ ,5[A< :^
M$I*'6^S1P;CU2.C,OPNA;C[UH627C//^1LJZDAO)TB+C3:W%D^Z20<U[_QZ0
M8#R;RR Q?HJ%\*#U:NG RRAC!0MF5>A&U35J^ TJNLC*CWW: 7PQP 7<\8K]
M*%K9!R,ML..%90`HN[XU2ALZQJL]8;*B!=1D67WSK#S
MR[:?GRW 8F)5]2^<MOI=*>U8_*<]OA_IE71_'^W\M^ZR-+&VRW(\.=!>8MUG

M9=OMZER:4AK/8A$^J0* =KO* S3>"JA;G<NX,<Y^FDM:`A_\LE IGAR4UB0D

M$3V(M-U-,[S\09;9"!I6;/T>QE3NUM%X&GQ + S"VQ!=_*O5_\A4_8<R 3S%

M2"<]H[N?7S:F*M>%;W5?ZT0%]>((CH 9%5XKV(BL;.\8?+\/FV&:>3RINX^1



MO.O_/KNXO!F=7AP-1J<GY\-K\:O08X/AZ^'5U7! D]?MLJ*IL1"?H*2%D;>;



MH<R)+"_2R$"M0VI_Y7_&ZUF&F63Z]&R^U^F98>T24.'6LEDB;7CT`4TC]\,X

M\C/)R C%]G9X7WZ*#P]_$RU'<KF>\M7H*^*%CX^U3<!AY;:/V0`,^K7A!+2 

M,YGS[4+W? /8ZIES*X9Q-?OP*$?8=]BSNFN1C,MS+>=A!&:$GL7"B[LSTH^,
MX1,>\L7K%Q:,$&-P")]+[U#N*RJ&4EK?K7)YV!EH\7,5UM%WNS SR^>?J X5

M71=*E"VTL=:#S-(ZQS-:>-N'6F(NY:_K;FD"5._>%_=KYFX9&[4J6[J9HCU?
M$?NW?ACA%:(#TEJ\&4S6*P-SI,J RR:Z77X[FJ?B :1J9TN\]:E'[HOCB_.;
MX8<;<[.4.F_E'2=SHU3,E.(KI">E]PM4_"(7>,-(S.%?KL![!GA)5XQ&DOP_
MW7X6 S-QO+U=%M*0J:8K6XJ-YNLNM5SAO_-WIZ>.SKQ![F4R+U==\EVLS'MC


MK&?B^**,\O75T=GPY;[(IC6$"[D`Z7KB>38E5<BF^FFS:-?X3#X_`:W,U +C

MIK+-4^-RJD$&!">Z*3H\N<0>#EY:_[RR83C[L$?,:^)'$:X?`4W].H >/7 M
M2U0B,.%IT%+R7]V6A^PPV : S !=7VX&&AN 5W6 K_7=0<I'09!>'G<O^*8H
MOP[=_*Z S]#MB

M+J;ZNL8AC]7N??"+%!S->+48A%D2 <^ 7RLT_:*^(3<NIE.9?BQ) %+MU<7I
MRWUCY-MBM[>W+S[5]KA<`Q<).S#S`' =HOV<MZHATJN:9V-(U^G, C/_[AQ$

MQ4!]X&%MW0 X939JAZV_;F `M.LKOS0-&\.;>,:!ZKT??7ZY[Q'K1Z]/3H>C
MLZ/CMZ!3HY,___RRX_()C5=9.3\&EH__&%",'8\`HVK]#X1[#LKR6J=/-QBW

MN/_TIVJ4XYG6[/H4;LHG1"9!S8\; _)4O9-F".  `GY53&IXF8XQ4.* O=\7

M.!!T";QLEV!OCG\*8+=E'4  0<SF8-5^SO "^C$6]U>HGV+:*>NOM<S5!82M

M`/8I9O C0:Y*N!H9XW4 X.P&\B3_3!-_-Z;PFUCZ*ZLPJ=.2XR]V,E O3B7I
M^CW]*%/_*HVEM^$<`0J%H"5\+A(NA7S(AX $O+ 520B$' +B*=IN/%:/[+'J
M>)5'QRJ&NB]_%YY".GRCCA+ZX"J &]O5]1*/72FF)<O_-RKIYM (FT?'5S?7
M2%>1W,\7BRLR5L5L[ *JMTT>(.J^T \8UW+ V5R)E7VXZH1NWX7*5(PS5"54

MCV)O$[T813"7HA!0S5#DXBAR"K/.,(*[6:'#BAW-Y
MN23WN&J<TNK7D)X9^7W3S ?_QXV1B^?%8BS3;]Z:^ `UMGUM?%^O^Q]&RUT;
MK[7]0V__0ZO3K"K:CCV;R!L=B7NA-Y'X<(^&C8Y, EVFHQOS>&'4G_2X9/'X
MCHR3"_7)!A^^DJNC&H'C)-6.50,EL\$)V"XYZ'&>W?GA7KSI4D747BK[;SB[
MD/E<Z2$:*']S_N'GE]3BM 9-1F'?X/MJ?WGZY%]02P$"% `4````" !N *$R
M&BLC?6,1``!30 ``!0`````````!`" ` ($`````9&5H+F-02P$"% `4````

M4$L!`A0`% ```` `QHVA,F0$5QW%!P``LAD```D``````````0` `("!N2(`
M`&1B9VAE;' N9%!+`0(4`!0````(`$ILGC*)Y11O7PL````T```+````````
M````( "  :4J``!D8F=H96QP+FQI8E!+`0(4`!0````(`))8HC)(HT![8Q(`
M`/-!```(``````````$`( "  2TV``!O8FIE8W0N9%!+!08`````!0`%`! !
(``"V2 ``````
`
end
May 02 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
Well done! That was fast, too.

[snip]

 Notes
 ==================
 Altough it does not currently work, the Exception could also be able
 to contain a 'cause' (i.e. another exception). In this case, the stack 
 trace
 would contain the cause exception, as in:
 Exception1:"message"
  ...
  ...
 Caused by:
 Exception2:"message"
  ...
  ...

 This is all already coded, but DMD itself currently expects
 Exception to have only one parameter... Walter could fix
 this, I can't.


agreed. Exception and Error need to be merged (or at least rationalized).

[snip]


 - Some Exceptions (e.g. StreamError) do not generate a stack frame at
  construction (even in debug version). Consequently, the stack trace
  reported is erroneous by one method call. I.e. it is not the reported
  function that has the exception but a function called
  by the reported function. There is unfortunately not much that I can do,
  it's Walter who's pulling the strings here. I suppose in debug version
  all functions should properly generate stack frames.


I'm curious about the StreamError (a "deprecated" alias of StreamException). 
Can you give more details? Is there something std.stream should do 
differently to get a stack trace?
May 02 2005
parent reply "Maxime Larose" <mlarose broadsoft.com> writes:
 - Some Exceptions (e.g. StreamError) do not generate a stack frame at
  construction (even in debug version). Consequently, the stack trace
  reported is erroneous by one method call. I.e. it is not the reported
  function that has the exception but a function called
  by the reported function. There is unfortunately not much that I can




do,

  it's Walter who's pulling the strings here. I suppose in debug version
  all functions should properly generate stack frames.


 I'm curious about the StreamError (a "deprecated" alias of


StreamException).

 Can you give more details? Is there something std.stream should do
 differently to get a stack trace?


Well, I don't know if it's deprecated or not, but it was used in unittest.d,
that's how I found out.

The problem is that it doesn't generate a stack frame. A stack frame is
generated with:
asm { enter 0,0; }
or the more traditional:
asm { push ebp; mov ebp,esp; }

Without having the frame, there is not way we can know who the caller of the
method was later on.

In this case, you have the following sequence (more or less):
main
  call methodA
methodA
  create a stack frame   // we will know who the caller to A was (main)
  call methodB
methodB
  new StreamError  // we will not know who the caller to B was (methodA)
StreamError.ctor
  new Error
Error.ctor
  create frame // we will know who the caller was, i.e. StreamError.ctor

Notice that in the above sequence, you will never know who the caller to
StreamError.ctor was (methodB). As far as the stack frame walker is
concerned, the calling sequence is:
main, methodA, StrearError.ctor, Error.ctor   (no methodB)
(the last one, Error.ctor, is found by directly checking the EIP register)

If stack frames are not created when optimizing, well, that makes sense. In
debug version however, each function should properly generate a stack frame
so no caller is missing from the stack trace.
I could sift through all the phobos files and all the methods and generate
the stack frames myself manually (I did that in some of the new classes).
However, there would be a ton of files impacted and I figure there is
probably a way for the compiler itself to better behave. So, this one is in
Walter-land... ;)


There is one thing worth mentioning. The hardware exceptions (access
violation, division by 0) get trapped by the OS when they occur, and
eventually D's handler is called. When that happens, we always miss the top
caller (the one that did the actual violation). This is most inconvenient.
I'm pretty sure there would be a way for us to get that info, thought I
haven't found out how yet... I'm waiting for Walter (or anyone) to tell me
how to do a try-except with DMC, then I'll make some more tests.
May 02 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Maxime Larose" <mlarose broadsoft.com> wrote in message 
news:d55pt2$28km$1 digitaldaemon.com...

 - Some Exceptions (e.g. StreamError) do not generate a stack frame at
  construction (even in debug version). Consequently, the stack trace
  reported is erroneous by one method call. I.e. it is not the reported
  function that has the exception but a function called
  by the reported function. There is unfortunately not much that I can




 do,

  it's Walter who's pulling the strings here. I suppose in debug version
  all functions should properly generate stack frames.


 I'm curious about the StreamError (a "deprecated" alias of


 StreamException).

 Can you give more details? Is there something std.stream should do
 differently to get a stack trace?


 Well, I don't know if it's deprecated or not, but it was used in 
 unittest.d,
 that's how I found out.


ok. I remember that unittest. It does that in order to force the std.stream 
unittests to get compiled. When I changed the names to StreamException I 
didn't want to touch other parts of phobos so that use stayed. A few other 
places refer to StreamError just like there are bunches of Error subclasses 
in phobos. Anyway, it's all waiting for a spring cleaning...


 The problem is that it doesn't generate a stack frame. A stack frame is
 generated with:
 asm { enter 0,0; }
 or the more traditional:
 asm { push ebp; mov ebp,esp; }

 Without having the frame, there is not way we can know who the caller of 
 the
 method was later on.

 In this case, you have the following sequence (more or less):
 main
  call methodA
 methodA
  create a stack frame   // we will know who the caller to A was (main)
  call methodB
 methodB
  new StreamError  // we will not know who the caller to B was (methodA)
 StreamError.ctor
  new Error
 Error.ctor
  create frame // we will know who the caller was, i.e. StreamError.ctor

 Notice that in the above sequence, you will never know who the caller to
 StreamError.ctor was (methodB). As far as the stack frame walker is
 concerned, the calling sequence is:
 main, methodA, StrearError.ctor, Error.ctor   (no methodB)
 (the last one, Error.ctor, is found by directly checking the EIP register)


Is the stack captured at the exception ctor or at the throw statement? Is it 
possible to trace from the throw? For example by modifying _d_throw in 
src/phobos/internal or something?


 If stack frames are not created when optimizing, well, that makes sense. 
 In
 debug version however, each function should properly generate a stack 
 frame
 so no caller is missing from the stack trace.
 I could sift through all the phobos files and all the methods and generate
 the stack frames myself manually (I did that in some of the new classes).
 However, there would be a ton of files impacted and I figure there is
 probably a way for the compiler itself to better behave. So, this one is 
 in
 Walter-land... ;)


hmm. I don't understand why StreamError is different than other exceptions, 
but it sounds complicated.


 There is one thing worth mentioning. The hardware exceptions (access
 violation, division by 0) get trapped by the OS when they occur, and
 eventually D's handler is called. When that happens, we always miss the 
 top
 caller (the one that did the actual violation). This is most inconvenient.
 I'm pretty sure there would be a way for us to get that info, thought I
 haven't found out how yet... I'm waiting for Walter (or anyone) to tell me
 how to do a try-except with DMC, then I'll make some more tests.
May 02 2005
parent reply "Maxime Larose" <mlarose broadsoft.com> writes:
 Is the stack captured at the exception ctor or at the throw statement? Is


it

 possible to trace from the throw? For example by modifying _d_throw in
 src/phobos/internal or something?


It is best to get the stack trace when creating the Exception. That is
because it then becomes a quick and easy way to get a stack trace and print
it (without the need for a dummy throw-catch). A possibility would be to add
the ability to re-compute the stack trace on an existing exception. However,
that can lead non-careful developers making it very difficult to find the
root cause to a problem.



 hmm. I don't understand why StreamError is different than other


exceptions,

 but it sounds complicated.


It is not just StreamError. StreamError was just an example.


I haven't heard from Walter yet, it's a bit annoying. The more I read this
newsgroup, the more I think he really underestimate the service we are all
making to D... As relatively young and immature as D is right now, having
its main/only architect being responsive is pretty much required to support
confidence in people investing time and energies in this project... The more
I read this newsgroup, the more I understand the "please walter respond"
pleas litering the place. Honestly, this frightens me quite a bit. I am not
sure anymore I was right to be so enthiusastic about D as I first was. It
shows great promise, of course, but Walter's focus remains unclear (or plain
wrong, IMO) on a number of topics.

Anyways, I realize having a GC'ed language might not be good for what I have
in mind. One idea I had to rewrite phobos now seems like a major overkill.
At any rate, I'll stick around a little more to see what unfolds...
May 03 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Maxime Larose" <mlarose broadsoft.com> wrote in message 
news:d58c31$2mal$1 digitaldaemon.com...

 Is the stack captured at the exception ctor or at the throw statement? Is


 it

 possible to trace from the throw? For example by modifying _d_throw in
 src/phobos/internal or something?


 It is best to get the stack trace when creating the Exception. That is
 because it then becomes a quick and easy way to get a stack trace and 
 print
 it (without the need for a dummy throw-catch). A possibility would be to 
 add
 the ability to re-compute the stack trace on an existing exception. 
 However,
 that can lead non-careful developers making it very difficult to find the
 root cause to a problem.


If a goal of the stack-trace feature is to dump stacks without throwing then 
why make it necessary to instantiate an exception? I'm thinking of an API 
like Java's Thread.dumpStack which dumps the stack of the code calling 
dumpStack. I think in the case of a thrown exception the stack should be at 
the throw since that is where the "error" truely happens and that's where a 
programmer would start debugging the issue.


 hmm. I don't understand why StreamError is different than other
 exceptions, but it sounds complicated.


 It is not just StreamError. StreamError was just an example.


ok


 I haven't heard from Walter yet, it's a bit annoying. The more I read this
 newsgroup, the more I think he really underestimate the service we are all
 making to D... As relatively young and immature as D is right now, having
 its main/only architect being responsive is pretty much required to 
 support
 confidence in people investing time and energies in this project... The 
 more
 I read this newsgroup, the more I understand the "please walter respond"
 pleas litering the place. Honestly, this frightens me quite a bit. I am 
 not
 sure anymore I was right to be so enthiusastic about D as I first was. It
 shows great promise, of course, but Walter's focus remains unclear (or 
 plain
 wrong, IMO) on a number of topics.


yeah - I think his posting rate has gone down lately. I didn't remember it 
being this bad before. One can sympathize with the desire to have a compiler 
that doesn't crash but IMO the rather esoteric bugs (eg crashes on unusual 
invalid code) he's tracking could be prioritized after some of the rather 
huge API changes people are talking about. There's almost no visibility into 
the development process so we're left to make our own assumptions about 
where this train is headed (and the speed at which it is traveling).


 Anyways, I realize having a GC'ed language might not be good for what I 
 have
 in mind. One idea I had to rewrite phobos now seems like a major overkill.
 At any rate, I'll stick around a little more to see what unfolds...


please do! You stack trace stuff should be very valuable.
May 03 2005
next sibling parent reply "Maxime Larose" <mlarose broadsoft.com> writes:
"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:d58db5$2o2h$1 digitaldaemon.com...

 If a goal of the stack-trace feature is to dump stacks without throwing


then

 why make it necessary to instantiate an exception? I'm thinking of an API
 like Java's Thread.dumpStack which dumps the stack of the code calling
 dumpStack. I think in the case of a thrown exception the stack should be


at

 the throw since that is where the "error" truely happens and that's where


a

 programmer would start debugging the issue.


Yes, I see your point and I agree. It would not be difficult to change what
I did for what you propose.
May 03 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <d58djs$2o9o$1 digitaldaemon.com>, Maxime Larose says...

"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:d58db5$2o2h$1 digitaldaemon.com...

 If a goal of the stack-trace feature is to dump stacks without throwing


then

 why make it necessary to instantiate an exception? I'm thinking of an API
 like Java's Thread.dumpStack which dumps the stack of the code calling
 dumpStack. I think in the case of a thrown exception the stack should be


at

 the throw since that is where the "error" truely happens and that's where


a

 programmer would start debugging the issue.


Yes, I see your point and I agree. It would not be difficult to change what
I did for what you propose.


Please do.  This would be a great feature to have.


Anyways, I realize having a GC'ed language might not be good for what I have
in mind. One idea I had to rewrite phobos now seems like a major overkill.


Been there, doing that ;)  Your stack trace feature will definately be in Ares,
whether it ends up in Phobos or not.


Sean
May 03 2005
parent reply "Maxime Larose" <mlarose broadsoft.com> writes:
 Been there, doing that ;)  Your stack trace feature will definately be in


Ares,

 whether it ends up in Phobos or not.


What is the design goals for Ares? I skimmed through the forum on dsource,
but couldn't find the reason for its existence...
(Sent me a RTFM with a link if I missed the obvious... ;)

Thanks
May 04 2005
parent Sean Kelly <sean f4.ca> writes:
In article <d5apue$27k6$1 digitaldaemon.com>, Maxime Larose says...

 Been there, doing that ;)  Your stack trace feature will definately be in


Ares,

 whether it ends up in Phobos or not.


What is the design goals for Ares? I skimmed through the forum on dsource,
but couldn't find the reason for its existence...
(Sent me a RTFM with a link if I missed the obvious... ;)


The birth of Ares largely stemmed from a general sense of frustration regarding
Phobos submissions (namely that such things often seemed ignored or, at best,
quite delayed before inclusion).  Some thought that perhaps a group of motivated
people could ease Walter's workload (and speed the development of Phobos) by
reviewing submissions and presenting them to Walter in a more structured manner.
A driving concern was that some don't consider Phobos to be up to snuff as a
standard library, and that it would speed the langauge's development if Walter
could focus on language issues and leave others to fuss over library
development.  Perhaps as a result of this dissatisfaction with existing Phobos
components, the Ares project changed rather quickly into one aimed at creating
an entirely new standard library, complete with accompanying spec.  As this is a
relatively large project that may prove to be ultimately futile (since Walter
has veto power on all things D), interest waned and that's pretty much where we
stand now.

I've continued development of Ares in my (recently limited) spare time and the
project has garnered some renewed interest from like-minded individuals.  Going
forward, I do expect Ares development to pick up substantially.  And whether or
not it's ultimately accepted or not, I plan to use it for my own programming
projects.  Currently, Ares represents a minimal runtime library for DMD (and
soon for GDC as well).  It consists of three pieces: ares, dmdrt, and dmdgc.
The latter two portions are code extracted from Phobos--dmdrt contains all
runtime code that the DMD compiler requires, and dmdgc is the GC shipped with
phobos (a driving concern for this separation was that the GC, runtime, and
standard library should all be independent from one another and only interact in
specific, structured ways--they're somewhat intertwined in Phobos).  Some
remaining pieces still need attention--the core exception structure needs some
refactoring, and the GC interface hasn't been touched--but for the most part I
think it makes a fairly solid starting point for development.  And once these
final details have been hammered out I expect that development will accelerate
quickly.

As for the manual, there isn't one yet :)  And as code has just begun to be
checked into the SVN repository (I'd been maintaining it on my home PC until
recently) there are likely some access issues there as well.  In the meantime, I
keep an up to date copy of the Ares source on my D "website":
http://home.f4.ca/sean/d


Sean
May 04 2005
prev sibling next sibling parent pragma <pragma_member pathlink.com> writes:
In article <d58db5$2o2h$1 digitaldaemon.com>, Ben Hinkle says...

 Anyways, I realize having a GC'ed language might not be good for what I 
 have
 in mind. One idea I had to rewrite phobos now seems like a major overkill.
 At any rate, I'll stick around a little more to see what unfolds...


please do! You stack trace stuff should be very valuable.


If I may say so, I'd add that this contribution is an *invaluable* service to
every last one of us here.  This feature was long overdue.

Thank you Maxime.

- EricAnderton at yahoo
May 03 2005
prev sibling parent reply John Demme <me teqdruid.com> writes:
On Tue, 2005-05-03 at 13:45 -0400, Ben Hinkle wrote:

 "Maxime Larose" <mlarose broadsoft.com> wrote in message 
 news:d58c31$2mal$1 digitaldaemon.com...




...

 If a goal of the stack-trace feature is to dump stacks without throwing then 
 why make it necessary to instantiate an exception? I'm thinking of an API 
 like Java's Thread.dumpStack which dumps the stack of the code calling 
 dumpStack. I think in the case of a thrown exception the stack should be at 
 the throw since that is where the "error" truely happens and that's where a 
 programmer would start debugging the issue.


I disagree, as I've done things like this in Java:
try {
	someMethod();
} catch (MyException e) {
	//Examine exception more closely
	if (ICanHandle(e)) {
		handle(e);
	} else {
		throw e;
	}
}

Now given, this is really just a work around for an extremely poor
Exception hierarchy, but I think it shows that the error doesn't
necessarily occur at the throw.  I'd say a stack trace should be
generated by the constructor (or not, depending on parameters) and also
have a method .generateST() to (re-)generate the ST for maximum
flexibility.

John Demme



 May 03 2005



  parent  "Ben Hinkle" <bhinkle mathworks.com>  writes:


"John Demme" <me teqdruid.com> wrote in message 
news:1115152504.21959.6.camel localhost.localdomain...

 On Tue, 2005-05-03 at 13:45 -0400, Ben Hinkle wrote:

 "Maxime Larose" <mlarose broadsoft.com> wrote in message
 news:d58c31$2mal$1 digitaldaemon.com...




 ...

 If a goal of the stack-trace feature is to dump stacks without throwing 
 then
 why make it necessary to instantiate an exception? I'm thinking of an API
 like Java's Thread.dumpStack which dumps the stack of the code calling
 dumpStack. I think in the case of a thrown exception the stack should be 
 at
 the throw since that is where the "error" truely happens and that's where 
 a
 programmer would start debugging the issue.


 I disagree, as I've done things like this in Java:
 try {
 someMethod();
 } catch (MyException e) {
 //Examine exception more closely
 if (ICanHandle(e)) {
 handle(e);
 } else {
 throw e;
 }
 }

 Now given, this is really just a work around for an extremely poor
 Exception hierarchy, but I think it shows that the error doesn't
 necessarily occur at the throw.  I'd say a stack trace should be
 generated by the constructor (or not, depending on parameters) and also
 have a method .generateST() to (re-)generate the ST for maximum
 flexibility.

 John Demme


The stack is generated at the original throw inside someMethod. I can buy 
the argument that if you rethrow an exception it doesn't step on the stack 
that is already there. You're right that it shouldn't lose the stack from 
the original throw/ctor. 



 May 03 2005