proposal: minimal language support for stack trace of exceptions and assert()
THORSTEN OTTOSEN
riming in google groups.
I would like the standard to specify that all compilers must specify
a -stack_trace compilation option which should supply the
following minimal requirements:
1) The file, function, line of an assert() and a thrown exception should
saved
2) The file, function, line of the code that called the code with the
assertion/exception should be saved
Implementations could then (if they wanted) provide much deeper logging. We
also need some way to query this information, the assertion
will simply print the information as usual, but with exceptions we need
something else:
namespace std
{
stack_context();
}
And/or maybe we could add another function to std::exception
char* std::exeption::stack_trace() throw() const
{
return stack_context();
}
to enable idiomatic use by
try
{
...
}
catch( std::exception& e )
{
cout << e.stack_trace();
}
Why does I want such a language change? Well, I think it's pretty near
impossible to get some runtime information about
*where* an exception/assertion stems from. I can only unelegantly trace
where it happened by
#define THROW( e ) { log( __LINE__, __FILE__ ); throw e; }
or add the silly information to the exceptions constructor. However, I can
never find out what called the code with the error.
I know that it's possible to examine the stack trace in a debugger, but
that's just not good enough: what if the errors happen
when the program is compiled with full optimization and has been deployed?
The program might be running ok, but there might be several
exceptions which I would like to inspect; the exceptions might only be
turning up in the "release" version, and not while I'm
making the program.
I supect such a language change will only have minimal impact on performance
and everybody will have the possibility to turn it of
if they want. I also suspect that it's "trivial" to implement for compiler
writers.
best regards
Thorsten
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Mirek Fidler
> a -stack_trace compilation option which should supply the
> following minimal requirements:
>
> 1) The file, function, line of an assert() and a thrown exception should
> saved
> 2) The file, function, line of the code that called the code with the
> assertion/exception should be saved
While this is good idea, I do not think language support is best option here. Compiler writers
are free to implement such feature now.
Plus, you can do such things now even without compiler support - all you need is stack dump and
.map file.
Mirek
Pavel Vozenilek
>
> Implementations could then (if they wanted) provide much deeper logging.
> Why does I want such a language change? Well, I think it's pretty near
> impossible to get some runtime information about
> *where* an exception/assertion stems from.
>
It is pretty hard but often possible to get stack trace information.
It is always platform specific: e.g. on Win32 with MAP files, PDB
files and function stack frames you may get what you want (it was
described in MSJ few years ago, I may look it up).
/Pavel
THORSTEN OTTOSEN
news:b1j2a6$17uc$1...@news.vol.cz...
> > I would like the standard to specify that all compilers must specify
> > a -stack_trace compilation option which should supply the
> > following minimal requirements:
> >
> > 1) The file, function, line of an assert() and a thrown exception should
> > saved
> > 2) The file, function, line of the code that called the code with the
> > assertion/exception should be saved
>
> While this is good idea, I do not think language support is best
option here. Compiler writers
> are free to implement such feature now.
but they won't do it unless it's mandatory, will they?
> Plus, you can do such things now even without compiler support - all
you need is stack dump and
> .map file.
Could you elaborate on this? I think I made it clear that we cannot get a
stack-dump of a running application. We have no means
of inspecting the exceptions in a running program.
regards
Thorsten
Stephen Howe
> a -stack_trace compilation option which should supply the
> following minimal requirements:
>
> 1) The file, function, line of an assert() and a thrown exception should
> saved
> 2) The file, function, line of the code that called the code with the
> assertion/exception should be saved
Well if so that sets a precedent. There is nothing in the standard which
says that compilers must specify any "compilation option". In fact I don't
think the standard does not say if an enviroment has a "stack" at all. The
only time it is mentioned is in the context of exceptions thrown and "stack
unwinding"
Stephen Howe
Mirek Fidler
> > > saved
> > > 2) The file, function, line of the code that called the code with the
> > > assertion/exception should be saved
> >
> > While this is good idea, I do not think language support is best
> option here. Compiler writers
> > are free to implement such feature now.
>
> but they won't do it unless it's mandatory, will they?
I am afraid they won't even if it is (as they do for other language features), but that is
another story....
> > Plus, you can do such things now even without compiler support - all
> you need is stack dump and
> > .map file.
>
> Could you elaborate on this? I think I made it clear that we cannot get a
> stack-dump of a running application. We have no means
> of inspecting the exceptions in a running program.
Not in standard defined way, that is true. OTOH, it can be done OS-specific way (we have such
support in our library under Win32 - when code crashes, stack dump .log is written to disk that can
be latter examined to find out what happened).
Mirek
White Wolf
> While this is good idea, I do not think language support is best
option here. Compiler writers
> are free to implement such feature now.
>
> Plus, you can do such things now even without compiler support -
all you need is stack dump and
> .map file.
Neither of which can be achieved by portable means. :-(
WW
THORSTEN OTTOSEN
news:731020ca.03020...@posting.google.com...
> nes...@cs.auc.dk ("THORSTEN OTTOSEN") wrote in message
news:<b1g8ca$97i$1...@sunsite.dk>...
> >
> > Implementations could then (if they wanted) provide much deeper logging.
> [snip]
> > Why does I want such a language change? Well, I think it's pretty near
> > impossible to get some runtime information about
> > *where* an exception/assertion stems from.
> >
> [snip]
>
> It is pretty hard but often possible to get stack trace information.
> It is always platform specific:
I guess then my proposal is to remove the platform specific part of it.
> e.g. on Win32 with MAP files, PDB
> files and function stack frames you may get what you want (it was
> described in MSJ few years ago, I may look it up).
MSJ?
regards
Thorsten
James Kanze
> ""Mirek Fidler"" <c...@volny.cz> wrote in message
> news:b1j2a6$17uc$1...@news.vol.cz...
> > > I would like the standard to specify that all compilers must
> > > specify a -stack_trace compilation option which should supply the
> > > following minimal requirements:
> > > 1) The file, function, line of an assert() and a thrown exception
> > > should saved
> > > 2) The file, function, line of the code that called the code with
> > > the assertion/exception should be saved
> > While this is good idea, I do not think language support is best
> option here. Compiler writers > are free to implement such feature
> now.
> but they won't do it unless it's mandatory, will they?
They'll do it if they think it will increase market share. A debugging
mode for the STL isn't mandatory either, and for a long time, was
pratically exceptional. But no decent implementation would be without it
today.
> > Plus, you can do such things now even without compiler support -
> > all you need is stack dump and .map file.
> Could you elaborate on this? I think I made it clear that we cannot
> get a stack-dump of a running application.
Not portably. I've got code which does it for Intel architectures and
Sparcs (different code in each case, of course).
> We have no means of inspecting the exceptions in a running program.
I'm not sure that this belongs in an exception. If you want to know
where it was raised, then exceptions are probably not the right tool.
--
James Kanze mailto:jka...@caicheuvreux.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
THORSTEN OTTOSEN
""Stephen Howe"" <SPAMstephe...@tnsofres.com> wrote in message
news:3e3e7dfd$0$234$ed9e...@reading.news.pipex.net...
> > I would like the standard to specify that all compilers must specify
> > a -stack_trace compilation option which should supply the
> > following minimal requirements:
> >
> > 1) The file, function, line of an assert() and a thrown exception should
> > saved
> > 2) The file, function, line of the code that called the code with the
> > assertion/exception should be saved
>
> Well if so that sets a precedent. There is nothing in the standard which
> says that compilers must specify any "compilation option".
does it really matter what the current standard says?
>In fact I don't
> think the standard does not say if an enviroment has a "stack" at all. The
> only time it is mentioned is in the context of exceptions thrown and
"stack
> unwinding"
so it does indeed say an implementation must have a stack. If "stack" is too
precise a word, then
let's use an -trace-function-calls options instead :-). Anyway, I'm not
interested in what we call such a feature, just to have it.
regards
Thorsten
THORSTEN OTTOSEN
> > > > 1) The file, function, line of an assert() and a thrown exception
should
> > > > saved
> > > > 2) The file, function, line of the code that called the code with
the
> > > > assertion/exception should be saved
> > >
> > > While this is good idea, I do not think language support is best
> > option here. Compiler writers
> > > are free to implement such feature now.
> >
> > but they won't do it unless it's mandatory, will they?
>
> I am afraid they won't even if it is (as they do for other language
features), but that is
> another story....
well, they might. Having a feature which is "recommended" by the standard
committee could push many compiler vendors
in the right direction.
> > > Plus, you can do such things now even without compiler support -
all
> > you need is stack dump and
> > > .map file.
> >
> > Could you elaborate on this? I think I made it clear that we cannot get
a
> > stack-dump of a running application. We have no means
> > of inspecting the exceptions in a running program.
>
> Not in standard defined way, that is true. OTOH, it can be done
OS-specific way (we have such
> support in our library under Win32 - when code crashes, stack dump .log is
written to disk that can
> be latter examined to find out what happened).
What can't you understand my point? :-) What should we do if we *don't* have
a stack trace and would like to keep the application running?
(it will seldom crash just because we caught an exception and continued the
program!) What if the
errors *cannot* be easily reproduced? What if the error occurs in the
realease version, but not in the debug version?
regards
Thorsten
THORSTEN OTTOSEN
"James Kanze" <ka...@gabi-soft.de> wrote in message
news:d6651fb6.03020...@posting.google.com...
> nes...@cs.auc.dk ("THORSTEN OTTOSEN") wrote in message
> news:<b1k2cp$kq2$1...@sunsite.dk>...
> > ""Mirek Fidler"" <c...@volny.cz> wrote in message
> > news:b1j2a6$17uc$1...@news.vol.cz...
> > > > I would like the standard to specify that all compilers must
> > > > specify a -stack_trace compilation option which should supply the
> > > > following minimal requirements:
> > > > 1) The file, function, line of an assert() and a thrown exception
> > > > should saved
> > > > 2) The file, function, line of the code that called the code with
> > > > the assertion/exception should be saved
>
> > > While this is good idea, I do not think language support is best
> > option here. Compiler writers > are free to implement such feature
> > now.
>
> > but they won't do it unless it's mandatory, will they?
>
> They'll do it if they think it will increase market share. A debugging
> mode for the STL isn't mandatory either, and for a long time, was
> pratically exceptional. But no decent implementation would be without it
> today.
however, the committee might push them in the right direction.
>
> > > Plus, you can do such things now even without compiler support -
> > > all you need is stack dump and .map file.
>
> > Could you elaborate on this? I think I made it clear that we cannot
> > get a stack-dump of a running application.
>
> Not portably. I've got code which does it for Intel architectures and
> Sparcs (different code in each case, of course).
>
> > We have no means of inspecting the exceptions in a running program.
>
> I'm not sure that this belongs in an exception. If you want to know
> where it was raised, then exceptions are probably not the right tool.
could you explain then what the right tool is? I hate to admit it, but the
stack trace you get in
Java is a pretty convenient thing. How can you possibly locate the "hot
spot" if you don't know what
generated the exception?
I think we have to admit (as you might have guessed) that this is something
really useful and something
that should not be missing in C++.
regards
Thorsten
Mirek Fidler
> option here. Compiler writers
> > are free to implement such feature now.
> >
> > Plus, you can do such things now even without compiler support -
> all you need is stack dump and
> > .map file.
>
> Neither of which can be achieved by portable means. :-(
Yes. Like most things that are done by current C++ software.
Mirek
Mirek Fidler
> OS-specific way (we have such
> > support in our library under Win32 - when code crashes, stack dump .log is
> written to disk that can
> > be latter examined to find out what happened).
>
> realease version, but not in the debug version?
Cases you cited above are exactly cases that drove us to add that support. We had application
that seldomly crashed at clients site in release mode. We made our simple crash stack dump and
analyzer and quite surprisingly, after one week we cought the bug...
BTW, that bug was rather interesting and unexpected (they tend to be so :) - code crashed due to
assigning double to int and double was out of int range. More interestingly, this bug did not
crashed application on our version of Windows, but in clients it did (or was it CPU difference ? who
knows...).
Sorry for being rather off-topic.
Mirek
Pavel Vozenilek
> "Pavel Vozenilek" <pavel_v...@yahoo.co.uk> wrote in message
> news:731020ca.03020...@posting.google.com...
> > nes...@cs.auc.dk ("THORSTEN OTTOSEN") wrote in message
> news:<b1g8ca$97i$1...@sunsite.dk>...
> MSJ?
>
Microsoft System Journal (http://www.microsoft.com/msj).
Matt Pietrek wrote few articles about stack trace, here's one:
http://www.microsoft.com/msj/defaultframe.asp?page=/msj/0597/hood0597.htm&nav=/msj/0597/newnav.htm.
/Pavel
Joerg Barfurth
> > I would like the standard to specify that all compilers must specify
> > a -stack_trace compilation option which should supply the
> > following minimal requirements:
I don't think the standard should specify compilation options.
> > 1) The file, function, line of an assert() and a thrown exception should
> > saved
There is __FILE__ and __LINE__. I agree that some ways to get a
representation of the current function name (maybe with different
qualification options ?) could be useful.
> > 2) The file, function, line of the code that called the code with the
> > assertion/exception should be saved
... nevertheless some builtin function-call backtrace support would be
useful. The question is what the requirements are. How far should it go?
Should any values from each stack fram (e.g. argument values) be
included? Does it need to be human-readable? How do we avoid imposing
overhead (e.g. to store necessary symbols) for those who don't use the
feature? Do we require implementation support to get useful information
out of the raw data (if it is not human-readable)? ...
> While this is good idea, I do not think language support is best
> option here. Compiler writers are free to implement such feature now.
Now this is a feature which in some way should be implementable on all
platforms in implementation-specific ways (especially if you know the
internal details), but which can't be done portably at all. Thus this is
a classic example of functionality, which should be provided by the
implementation. And having a standard interface for accessing it, is
useful for obvious reasons.
> Plus, you can do such things now even without compiler support - all
> you need is stack dump and .map file.
The difficult thing is getting a stack dump. You can't do that portably,
if the standard doesn't help you.
Regards, Jörg
--
Jörg Barfurth barf...@gmx.net
<<<<<<<<<<<<< using std::disclaimer; <<<<<<<<<<<<<<<<<<<<<<<<<<<<
Software Developer http://util.openoffice.org
StarOffice Configuration # Deutsch:http://de.openoffice.org
James Kanze
> "James Kanze" <ka...@gabi-soft.de> wrote in message
> news:d6651fb6.03020...@posting.google.com...
> > nes...@cs.auc.dk ("THORSTEN OTTOSEN") wrote in message
> > news:<b1k2cp$kq2$1...@sunsite.dk>...
> > > ""Mirek Fidler"" <c...@volny.cz> wrote in message
> > > news:b1j2a6$17uc$1...@news.vol.cz...
> > > > > I would like the standard to specify that all compilers must
> > > > > specify a -stack_trace compilation option which should supply
> > > > > the following minimal requirements:
> > > > > 1) The file, function, line of an assert() and a thrown
> > > > > exception should saved
> > > > > 2) The file, function, line of the code that called the code
> > > > > with the assertion/exception should be saved
> > > > While this is good idea, I do not think language support is best
> > > option here. Compiler writers are free to implement such feature
> > > now.
> > > but they won't do it unless it's mandatory, will they?
> > They'll do it if they think it will increase market share. A
> > debugging mode for the STL isn't mandatory either, and for a long
> > time, was pratically exceptional. But no decent implementation would
> > be without it today.
> however, the committee might push them in the right direction.
Formally, the committee doesn't define recommended practices. It's
either a requirement, or it isn't. Since it isn't a reasonable
requirement for all systems (you wouldn't want it in an embedded
system), it won't find its way into the standard.
There are exceptions to this rule, things like §5.2.10/2 "[...
concerning the mapping between pointers and integers] it is intended to
be unsurprising to those who know the addressing structure of the
underlying machine." This is in a non-normative note, of course, but it
does give a hint to the implementor.
I'm not sure how something like this could be formulated to suggest that
implementations should provide additional functions in std::exception
providing line number and file where the exception was raised. I'm not
really convinced that it is such a good idea anyway.
> > > > Plus, you can do such things now even without compiler
> > > > support - all you need is stack dump and .map file.
> > > Could you elaborate on this? I think I made it clear that we
> > > cannot get a stack-dump of a running application.
> > Not portably. I've got code which does it for Intel architectures
> > and Sparcs (different code in each case, of course).
> > > We have no means of inspecting the exceptions in a running
> > > program.
> > I'm not sure that this belongs in an exception. If you want to know
> > where it was raised, then exceptions are probably not the right
> > tool.
> could you explain then what the right tool is?
To do what? Exceptions are NOT debugging tools, at least not in C++.
As David Abraham has pointed out, you DON'T want errors (like stack
overflow or segment violation) mapped to exceptions. Exception safe
code becomes impossible if you do.
Exceptions are for exceptional conditions, but only when the program
isn't yet corrupted, and only at expected times and places. Bad_alloc
is a perfect example -- and why on earth would you want a stack trace
when you get a bad_alloc?
> I hate to admit it, but the stack trace you get in Java is a pretty
> convenient thing.
It's sometimes (very rarely) convenient to be able to get a stack trace.
In Java, this is normally done by instantiating a java.lang.Throwable.
I've never seen a case in Java where I've looked at the stack trace of
an exception I've thrown, however. You sometimes might look at the
stack trace of an exception resulting from a programming error in Java.
This is because Java converts just about everything into an exception.
With the results that you cannot write really robust applications in
Java.
> How can you possibly locate the "hot spot" if you don't know what
> generated the exception?
I'm not sure what you mean by "hot spot" here. The meaning I know for
"hot spot" is a place where the code spends most of its execution time.
And the tool to find it is a profiler -- I don't see where exceptions
come into play.
> I think we have to admit (as you might have guessed) that this is
> something really useful and something that should not be missing in
> C++.
I'd not object to some sort of standardized interface for obtaining (and
maybe for printing out) a stack trace. But I wouldn't consider it an
essential feature. But I certainly don't want it intruding into
exceptions. Just because Java made a mistake doesn't mean that we
should do likewise.
--
James Kanze mailto:jka...@caicheuvreux.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
---
John Nagle
the commitee is that "assert" is one of the few C++ constructs
that still must be implemented with a preprocessor macro.
Suppose we added some built-in functions to namespace "std",
to obtain the file name and line number, as we now do with macros:
void assert(const char* msg,
const char* filename = std::current_source_file(),
int linenumber = std::current_line_number());
"std::current_source_file()" would return the name of the file
currently being compiled, and "std::current_line_number()" would
behave similarly. We do this now with a macro, but as will be
seen, it's better to do it within the language.
It would be appropriate for these functions to return the
position in the main compilation, so that if they're used in
a template or an inline, the location of the invocation, not
the template or inline definition, is returned. This is a big
win; diagnostics for trouble in templates would improve
substantially.
Constructors for exception objects could be defined in
such a way that when their exception is thrown, the error
location is filled in by this mechanism. This would add
location information to exceptions, when the programmer
wanted it. It might be worth adding the appropriate fields
to the standard exceptions, as default parameters, which
is backwards compatible with existing code.
John Nagle
Animats
Mirek Fidler wrote:
>>>>1) The file, function, line of an assert() and a thrown exception should
>>>>saved
---
James Kuyper
...
> Exceptions are for exceptional conditions, but only when the program
> isn't yet corrupted, and only at expected times and places. Bad_alloc
> is a perfect example -- and why on earth would you want a stack trace
> when you get a bad_alloc?
If the bad_alloc is thrown as a result of accidentally allocating an
object that was much larger than you expected it to be, there's a good
chance (though it's not guaranteed) that the bad_alloc will be thrown
during the allocation of that object. In that case, it could be useful
to track down where that bad_alloc was occurring.
However, I think this is something to be handled by a debugger, and
not something suitable for standardization as an intrinsic part of the
language.
Robert Klemme
"James Kuyper" <kuy...@wizard.net> schrieb im Newsbeitrag
news:8b42afac.03020...@posting.google.com...
> ka...@gabi-soft.de (James Kanze) wrote in message
news:<d6651fb6.03020...@posting.google.com>...
> ...
> > Exceptions are for exceptional conditions, but only when the program
> > isn't yet corrupted, and only at expected times and places. Bad_alloc
> > is a perfect example -- and why on earth would you want a stack trace
> > when you get a bad_alloc?
> However, I think this is something to be handled by a debugger, and
> not something suitable for standardization as an intrinsic part of the
> language.
I've found the Java approach very convenient, that each exception is
capable of producing a stack trace in human readable format. This comes in
very handy if an exception terminates a thread and the VM prints a trace -
or you catch the exception yourself and log it somewhere. You get to
appreciate this if your software fails on the client's site and he is able
to provide this trace to you. Clients typically don't run their
applications in debuggers... :-)
Regards
robert
James Kanze
news:<b1u6cc$17ef8j$1...@ID-52924.news.dfncis.de>...
> "James Kuyper" <kuy...@wizard.net> schrieb im Newsbeitrag
> news:8b42afac.03020...@posting.google.com...
> > ka...@gabi-soft.de (James Kanze) wrote in message
> news:<d6651fb6.03020...@posting.google.com>...
> > ...
> > > Exceptions are for exceptional conditions, but only when the
> > > program isn't yet corrupted, and only at expected times and
> > > places. Bad_alloc is a perfect example -- and why on earth would
> > > you want a stack trace when you get a bad_alloc?
> [snip]
> > However, I think this is something to be handled by a debugger, and
> > not something suitable for standardization as an intrinsic part of
> > the language.
> I've found the Java approach very convenient, that each exception is
> capable of producing a stack trace in human readable format. This
> comes in very handy if an exception terminates a thread and the VM
> prints a trace - or you catch the exception yourself and log it
> somewhere. You get to appreciate this if your software fails on the
> client's site and he is able to provide this trace to you. Clients
> typically don't run their applications in debuggers... :-)
I've found it very convenient to be able to get a stack trace. I've not
found it convenient that things like VirtualMachineError result in an
exception; it means that basically, you can get an exception at anytime,
which in practice makes it impossible to write a correct program.
In practice, of course, everyone ignores this possibility. The fact
that everything is on the heap, however, means that even things like
OutOfMemory can probably not be handled by exceptions in a correct
program.
As for clients not running their applications in debuggers... You get a
core dump, which has all the stack traces you need (and the stack hasn't
been unwound, so you can still get at the context). But that sort of
thing doesn't happen at the client site -- most of the places I've
worked have had a policy not to release code which didn't work (and most
of the time, there have been contractual penalties if it didn't work).
--
James Kanze mailto:jka...@caicheuvreux.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
---
THORSTEN OTTOSEN
news:d6651fb6.03020...@posting.google.com...
> nes...@cs.auc.dk ("THORSTEN OTTOSEN") wrote in message
> > > > Could you elaborate on this? I think I made it clear that we
> > > > cannot get a stack-dump of a running application.
>
> > > Not portably. I've got code which does it for Intel architectures
> > > and Sparcs (different code in each case, of course).
>
> > > > We have no means of inspecting the exceptions in a running
> > > > program.
>
> > > I'm not sure that this belongs in an exception. If you want to know
> > > where it was raised, then exceptions are probably not the right
> > > tool.
>
> > could you explain then what the right tool is?
>
> To do what?
is it really hard to see?
> Exceptions are NOT debugging tools, at least not in C++.
> As David Abraham has pointed out, you DON'T want errors (like stack
> overflow or segment violation) mapped to exceptions.
never said I wanted that.
> Exception safe
> code becomes impossible if you do.
probably, but another discussion.
> Exceptions are for exceptional conditions, but only when the program
> isn't yet corrupted, and only at expected times and places.
you don't have to teach me that
>Bad_alloc
> is a perfect example -- and why on earth would you want a stack trace
> when you get a bad_alloc?
maybe I don't, but then I simply don't make a query for the information.
>
> > I hate to admit it, but the stack trace you get in Java is a pretty
> > convenient thing.
>
> It's sometimes (very rarely) convenient to be able to get a stack trace.
on the contrary: e.g. in unit testing it is nice to know exactly where the
error occured without
letting the unit test abort the whole test; you would also be interested in
knowing what exceptions
that occured at a customers implementation etc.
> In Java, this is normally done by instantiating a java.lang.Throwable.
> I've never seen a case in Java where I've looked at the stack trace of
> an exception I've thrown, however. You sometimes might look at the
> stack trace of an exception resulting from a programming error in Java.
that's why I suggested assert to be changed too, since it really irritating
not to know exactly where
an STL iterator was used wrongly.
> This is because Java converts just about everything into an exception.
> With the results that you cannot write really robust applications in
> Java.
perhaps, but that is still another discussion; I have never wanted to turn
everything into an exception.
>
> > How can you possibly locate the "hot spot" if you don't know what
> > generated the exception?
>
> I'm not sure what you mean by "hot spot" here. The meaning I know for
> "hot spot" is a place where the code spends most of its execution time.
> And the tool to find it is a profiler -- I don't see where exceptions
> come into play.
I meant the place in the code where the error originated from, it could be
the first or second function
in a stack trace. This information is hard to guess.
>
> > I think we have to admit (as you might have guessed) that this is
> > something really useful and something that should not be missing in
> > C++.
>
> I'd not object to some sort of standardized interface for obtaining (and
> maybe for printing out) a stack trace. But I wouldn't consider it an
> essential feature.
then answer these non-essential questions for me:
1) a STL debug iterator reports an error; how do I quickly determine where
the error occured (the caller) without using a debugger
(the debugger process can be slow)
2) in a running program installed a costumer; how do inspect the exceptions
of his copy of the program? How do I reproduce such errors?
>But I certainly don't want it intruding into
> exceptions. Just because Java made a mistake doesn't mean that we
> should do likewise.
we're not.
regards
Thorsten
Mirek Fidler
>> you need is stack dump and .map file.
> The difficult thing is getting a stack dump. You can't do that portably,
> if the standard doesn't help you.
I agree that library support for stack dumping would not be bad. OTOH, there is a lot of other
things without std library support that are done regularly, so I do not care too much...
BTW, while being non-portable, stack dump is not hard part here. Examining it is much harder and
it is not possible to be made portable...
Mirek
Allan W
> In fact I don't
> think the standard does not say if an enviroment has a "stack" at all. The
> only time it is mentioned is in the context of exceptions thrown and "stack
> unwinding"
Perhaps that's the only explicit use of the word stack, but it is very
nearly a de-facto requirement. Recursion cannot work properly without
some sort of "call stack." Self-recursion (i.e. function "factorial")
is easy to detect, but mutual recursion between two functions is harder,
and if they're in separate compilation units it may be neigh impossible.
A keyword or some special syntax for possibly-recursive functions would
have solved this, but C++ doesn't even define such a keyword, much less
mandate it's use.
The practical upshot is, there has to be a call stack -- and not just
for calls that we know are mutually recursive, because in the general
case we simply don't know.
llewelly
[snip]
> > I hate to admit it, but the stack trace you get in Java is a pretty
> > convenient thing.
>
> It's sometimes (very rarely) convenient to be able to get a stack
> trace.
Rarely? You must program in a very different enviroment/style than I
do. For anything over ~200 lines, a stack trace is my most-used
debugging tool, whether comes form stack trace printing code I've
written, or from a debugger.
> In Java, this is normally done by instantiating a java.lang.Throwable.
> I've never seen a case in Java where I've looked at the stack trace of
> an exception I've thrown, however.
First time I've ever heard a Java programmer say *that*. Every Java
project I've worked on, as soon as there's a problem, programmers go
looking for stack traces. Programmers throw exceptions for all
kinds of errors, primariliy so they can get stack traces when the
error happens. Possibly you don't have that behavior because you
aren't principly a Java programmer.
> You sometimes might look at the
Sometimes? For every other Java programmer I know, its
*everytime*. (Except when the programmer error doesn't result in a
thrown exception.) I've seen lots of Java projects that use
exceptions for the same purposes some STL implementations use
concept checkers. (Yes I agree compile time error message are
superior - but I often don't know how to do that in Java.)
> stack trace of an exception resulting from a programming error in Java.
> This is because Java converts just about everything into an exception.
> With the results that you cannot write really robust applications in
> Java.
>
> > How can you possibly locate the "hot spot" if you don't know what
> > generated the exception?
>
> I'm not sure what you mean by "hot spot" here. The meaning I know for
> "hot spot" is a place where the code spends most of its execution time.
> And the tool to find it is a profiler -- I don't see where exceptions
> come into play.
>
> > I think we have to admit (as you might have guessed) that this is
> > something really useful and something that should not be missing in
> > C++.
I think we have to admit that though the standard says nothing about
it, it is not exactly missing from most C++ enviroments; many
implementations have an associated debugger which has a stack
trace functionality. It just isn't in the form Java programmers
expect. And of course it isn't in a form that aids in
logging/tracking bugs found by clients.
> I'd not object to some sort of standardized interface for obtaining (and
> maybe for printing out) a stack trace. But I wouldn't consider it an
> essential feature. But I certainly don't want it intruding into
> exceptions. Just because Java made a mistake doesn't mean that we
> should do likewise.
[snip]
I often wish for - and have implemented (in a platform-specific way) -
a C++ stack trace printing tool, but (like James) I don't want it
bound to exceptions. In my experience, the fact that Java wants
you to throw an exception to print a stack trace is annoying, and
makes it useless for debugging certain kinds of problems. If
print_stack_trace() isn't bound to exceptions, one can make a base
class for all one's exceptions - stack_trace_printing_exception -
which calls print_stack_trace() in its constructor, and derive all
exceptions from that. Or any of several cleaner alternatives.
Finally, I see some potential pitfalls in specifiying stack trace
functionality in the C++ standard. Since I've worked on projects
that couldn't fit into the memory of the release hardware when
built with debugging info, I'm afraid requiring demangled names
and function parameter values might be too much overhead for some
implementations. Ideally, one would get hex addresses if debugging
was disabled, and demangled names if debugging was enabled. But
the standard says nothing about debugging vs non-debugging
modes. Yet I don't want it to go the way of type_info::name(),
whose output can't be relied upon to be of any value. But perhaps
that would enough; I still use type_info::name() for some
debugging purposes.
THORSTEN OTTOSEN
news:1fptuqd.16k8jkjfahndiN%barf...@gmx.net...
> > I would like the standard to specify that all compilers must specify
> > a -stack_trace compilation option which should supply the
> > following minimal requirements:
>I don't think the standard should specify compilation options.
ok, I guess it was just to make a suggestion. I can understand the need
implementation defined specifications.
> > 1) The file, function, line of an assert() and a thrown exception should
> > saved
>There is __FILE__ and __LINE__. I agree that some ways to get a
>representation of the current function name (maybe with different
>qualification options ?) could be useful.
the c99 __func__ macro is avaiable on some C++ compilers already.
> > 2) The file, function, line of the code that called the code with the
> > assertion/exception should be saved
>... nevertheless some builtin function-call backtrace support would be
>useful. The question is what the requirements are. How far should it go?
long enough to give a good chance of discovering where the error is
manifested. I suggested
one level; maybe two would be ok too. Having this simple knowledge give a
sígnificant hint of where the error
might be (in both debugging and production code); this information can be
produced today with a lot of macro
magic and it is done so by e.g. unit testing frame works, but the
implementation is tedious and inelegant.
>Should any values from each stack fram (e.g. argument values) be
>included?
I would say it is of lesser value and therefore it could be omitted. The
really big step is to know (circa) what code that generated the error. For
production code, we have no means of that today.
>Does it need to be human-readable?
yes; or it should at least be easily converted into something readable by a
tool.
>How do we avoid imposing
>overhead (e.g. to store necessary symbols) for those who don't use the
>feature?
I guess that's what my compilation option is for.
>Do we require implementation support to get useful information
>out of the raw data (if it is not human-readable)? ...
yes.
regards
Thorsten
Stephen Howe
> > says that compilers must specify any "compilation option".
>
> does it really matter what the current standard says?
Yes it does. There is a section in "Design and Evolution of C++" where it
talks about extension proposals. Really everyone who proposes an extension
should read Bjarne's book.
> so it does indeed say an implementation must have a stack. If "stack" is
too
> precise a word, then
> let's use an -trace-function-calls options instead :-). Anyway, I'm not
> interested in what we call such a feature, just to have it.
Well I don't the standard should mandate it and I would oppose such a move
on the grounds that the overhead of providing such a facility for all C++
environments might be steep. Just to set you thinking
(i) Many compilers have a facility where assembler language is generated for
the chip in question. It can be useful. Should the standard mandate such a
compilation option is available on all C++ compilers?
(ii) Many compilers have a facility where a preprocessor listing can be
generated of the source. It can be useful. Should the standard mandate such
a compilation option is available on all C++ compilers?
The fact is, there is an endless series of "useful" compiler facilities.
Should the standard mandate what is "useful"? IMHO, no. This is where QoI
comes in and it should be left up to the compiler vendor to provide such
facilities.
Stephen Howe