382 lines
15 KiB
HTML
382 lines
15 KiB
HTML
|
<HTML>
|
||
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||
|
|
<!-- Created on March, 27 2008 by texi2html 1.64 -->
|
||
|
|
<!--
|
||
|
|
Written by: Lionel Cons <Lionel.Cons@cern.ch> (original author)
|
||
|
|
Karl Berry <karl@freefriends.org>
|
||
|
|
Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
||
|
|
and many others.
|
||
|
|
Maintained by: Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
||
|
|
Send bugs and suggestions to <texi2html@mathematik.uni-kl.de>
|
||
|
|
|
||
|
|
-->
|
||
|
|
<HEAD>
|
||
|
|
<TITLE>Debugging with GDB: GDB Bugs</TITLE>
|
||
|
|
|
||
|
|
<META NAME="description" CONTENT="Debugging with GDB: GDB Bugs">
|
||
|
|
<META NAME="keywords" CONTENT="Debugging with GDB: GDB Bugs">
|
||
|
|
<META NAME="resource-type" CONTENT="document">
|
||
|
|
<META NAME="distribution" CONTENT="global">
|
||
|
|
<META NAME="Generator" CONTENT="texi2html 1.64">
|
||
|
|
|
||
|
|
</HEAD>
|
||
|
|
|
||
|
|
<BODY LANG="" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000">
|
||
|
|
|
||
|
|
<A NAME="SEC654"></A>
|
||
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
||
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_26.html#SEC653"> < </A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_27.html#SEC655"> > </A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_4.html#SEC14"> << </A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb.html#SEC_Top"> Up </A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_28.html#SEC657"> >> </A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb.html#SEC_Top">Top</A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_toc.html#SEC_Contents">Contents</A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_38.html#SEC764">Index</A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_abt.html#SEC_About"> ? </A>]</TD>
|
||
|
|
</TR></TABLE>
|
||
|
|
<H1> 26. Reporting Bugs in GDB </H1>
|
||
|
|
<!--docid::SEC654::-->
|
||
|
|
<P>
|
||
|
|
|
||
|
|
Your bug reports play an essential role in making GDB reliable.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
Reporting a bug may help you by bringing a solution to your problem, or it
|
||
|
|
may not. But in any case the principal function of a bug report is to help
|
||
|
|
the entire community by making the next version of GDB work better. Bug
|
||
|
|
reports are your contribution to the maintenance of GDB.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
In order for a bug report to serve its purpose, you must include the
|
||
|
|
information that enables us to fix the bug.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
<BLOCKQUOTE><TABLE BORDER=0 CELLSPACING=0>
|
||
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gdb_27.html#SEC655">26.1 Have You Found a Bug?</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Have you found a bug?</TD></TR>
|
||
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gdb_27.html#SEC656">26.2 How to Report Bugs</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">How to report bugs</TD></TR>
|
||
|
|
</TABLE></BLOCKQUOTE>
|
||
|
|
<P>
|
||
|
|
|
||
|
|
<A NAME="Bug Criteria"></A>
|
||
|
|
<HR SIZE="6">
|
||
|
|
<A NAME="SEC655"></A>
|
||
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
||
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_27.html#SEC654"> < </A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_27.html#SEC656"> > </A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_27.html#SEC654"> << </A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_27.html#SEC654"> Up </A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_28.html#SEC657"> >> </A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb.html#SEC_Top">Top</A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_toc.html#SEC_Contents">Contents</A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_38.html#SEC764">Index</A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_abt.html#SEC_About"> ? </A>]</TD>
|
||
|
|
</TR></TABLE>
|
||
|
|
<H2> 26.1 Have You Found a Bug? </H2>
|
||
|
|
<!--docid::SEC655::-->
|
||
|
|
<P>
|
||
|
|
|
||
|
|
If you are not sure whether you have found a bug, here are some guidelines:
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
<UL>
|
||
|
|
<A NAME="IDX1326"></A>
|
||
|
|
<A NAME="IDX1327"></A>
|
||
|
|
<A NAME="IDX1328"></A>
|
||
|
|
<LI>
|
||
|
|
If the debugger gets a fatal signal, for any input whatever, that is a
|
||
|
|
GDB bug. Reliable debuggers never crash.
|
||
|
|
<P>
|
||
|
|
|
||
|
|
<A NAME="IDX1329"></A>
|
||
|
|
<LI>
|
||
|
|
If GDB produces an error message for valid input, that is a
|
||
|
|
bug. (Note that if you're cross debugging, the problem may also be
|
||
|
|
somewhere in the connection to the target.)
|
||
|
|
<P>
|
||
|
|
|
||
|
|
<A NAME="IDX1330"></A>
|
||
|
|
<LI>
|
||
|
|
If GDB does not produce an error message for invalid input,
|
||
|
|
that is a bug. However, you should note that your idea of
|
||
|
|
"invalid input" might be our idea of "an extension" or "support
|
||
|
|
for traditional practice".
|
||
|
|
<P>
|
||
|
|
|
||
|
|
<LI>
|
||
|
|
If you are an experienced user of debugging tools, your suggestions
|
||
|
|
for improvement of GDB are welcome in any case.
|
||
|
|
</UL>
|
||
|
|
<P>
|
||
|
|
|
||
|
|
<A NAME="Bug Reporting"></A>
|
||
|
|
<HR SIZE="6">
|
||
|
|
<A NAME="SEC656"></A>
|
||
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
||
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_27.html#SEC655"> < </A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_28.html#SEC657"> > </A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_27.html#SEC654"> << </A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_27.html#SEC654"> Up </A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_28.html#SEC657"> >> </A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb.html#SEC_Top">Top</A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_toc.html#SEC_Contents">Contents</A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_38.html#SEC764">Index</A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_abt.html#SEC_About"> ? </A>]</TD>
|
||
|
|
</TR></TABLE>
|
||
|
|
<H2> 26.2 How to Report Bugs </H2>
|
||
|
|
<!--docid::SEC656::-->
|
||
|
|
<P>
|
||
|
|
|
||
|
|
A number of companies and individuals offer support for GNU products.
|
||
|
|
If you obtained GDB from a support organization, we recommend you
|
||
|
|
contact that organization first.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
You can find contact information for many support companies and
|
||
|
|
individuals in the file <TT>`etc/SERVICE'</TT> in the GNU Emacs
|
||
|
|
distribution.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
In any event, we also recommend that you submit bug reports for
|
||
|
|
GDB. The preferred method is to submit them directly using
|
||
|
|
<A HREF="http://www.gnu.org/software/gdb/bugs/">GDB's Bugs web
|
||
|
|
page</A>. Alternatively, the <A HREF="mailto:bug-gdb@gnu.org">e-mail gateway</A> can
|
||
|
|
be used.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
<STRONG>Do not send bug reports to <SAMP>`info-gdb'</SAMP>, or to
|
||
|
|
<SAMP>`help-gdb'</SAMP>, or to any newsgroups.</STRONG> Most users of GDB do
|
||
|
|
not want to receive bug reports. Those that do have arranged to receive
|
||
|
|
<SAMP>`bug-gdb'</SAMP>.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
The mailing list <SAMP>`bug-gdb'</SAMP> has a newsgroup <SAMP>`gnu.gdb.bug'</SAMP> which
|
||
|
|
serves as a repeater. The mailing list and the newsgroup carry exactly
|
||
|
|
the same messages. Often people think of posting bug reports to the
|
||
|
|
newsgroup instead of mailing them. This appears to work, but it has one
|
||
|
|
problem which can be crucial: a newsgroup posting often lacks a mail
|
||
|
|
path back to the sender. Thus, if we need to ask for more information,
|
||
|
|
we may be unable to reach you. For this reason, it is better to send
|
||
|
|
bug reports to the mailing list.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
The fundamental principle of reporting bugs usefully is this:
|
||
|
|
<STRONG>report all the facts</STRONG>. If you are not sure whether to state a
|
||
|
|
fact or leave it out, state it!
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
Often people omit facts because they think they know what causes the
|
||
|
|
problem and assume that some details do not matter. Thus, you might
|
||
|
|
assume that the name of the variable you use in an example does not matter.
|
||
|
|
Well, probably it does not, but one cannot be sure. Perhaps the bug is a
|
||
|
|
stray memory reference which happens to fetch from the location where that
|
||
|
|
name is stored in memory; perhaps, if the name were different, the contents
|
||
|
|
of that location would fool the debugger into doing the right thing despite
|
||
|
|
the bug. Play it safe and give a specific, complete example. That is the
|
||
|
|
easiest thing for you to do, and the most helpful.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
Keep in mind that the purpose of a bug report is to enable us to fix the
|
||
|
|
bug. It may be that the bug has been reported previously, but neither
|
||
|
|
you nor we can know that unless your bug report is complete and
|
||
|
|
self-contained.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
Sometimes people give a few sketchy facts and ask, "Does this ring a
|
||
|
|
bell?" Those bug reports are useless, and we urge everyone to
|
||
|
|
<EM>refuse to respond to them</EM> except to chide the sender to report
|
||
|
|
bugs properly.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
To enable us to fix the bug, you should include all these things:
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
<UL>
|
||
|
|
<LI>
|
||
|
|
The version of GDB. GDB announces it if you start
|
||
|
|
with no arguments; you can also print it at any time using <CODE>show
|
||
|
|
version</CODE>.
|
||
|
|
<P>
|
||
|
|
|
||
|
|
Without this, we will not know whether there is any point in looking for
|
||
|
|
the bug in the current version of GDB.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
<LI>
|
||
|
|
The type of machine you are using, and the operating system name and
|
||
|
|
version number.
|
||
|
|
<P>
|
||
|
|
|
||
|
|
<LI>
|
||
|
|
What compiler (and its version) was used to compile GDB---e.g.
|
||
|
|
"gcc--2.8.1".
|
||
|
|
<P>
|
||
|
|
|
||
|
|
<LI>
|
||
|
|
What compiler (and its version) was used to compile the program you are
|
||
|
|
debugging--e.g. "gcc--2.8.1", or "HP92453-01 A.10.32.03 HP
|
||
|
|
C Compiler". For GCC, you can say <KBD>gcc --version</KBD>
|
||
|
|
to get this information; for other compilers, see the documentation for
|
||
|
|
those compilers.
|
||
|
|
<P>
|
||
|
|
|
||
|
|
<LI>
|
||
|
|
The command arguments you gave the compiler to compile your example and
|
||
|
|
observe the bug. For example, did you use <SAMP>`-O'</SAMP>? To guarantee
|
||
|
|
you will not omit something important, list them all. A copy of the
|
||
|
|
Makefile (or the output from make) is sufficient.
|
||
|
|
<P>
|
||
|
|
|
||
|
|
If we were to try to guess the arguments, we would probably guess wrong
|
||
|
|
and then we might not encounter the bug.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
<LI>
|
||
|
|
A complete input script, and all necessary source files, that will
|
||
|
|
reproduce the bug.
|
||
|
|
<P>
|
||
|
|
|
||
|
|
<LI>
|
||
|
|
A description of what behavior you observe that you believe is
|
||
|
|
incorrect. For example, "It gets a fatal signal."
|
||
|
|
<P>
|
||
|
|
|
||
|
|
Of course, if the bug is that GDB gets a fatal signal, then we
|
||
|
|
will certainly notice it. But if the bug is incorrect output, we might
|
||
|
|
not notice unless it is glaringly wrong. You might as well not give us
|
||
|
|
a chance to make a mistake.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
Even if the problem you experience is a fatal signal, you should still
|
||
|
|
say so explicitly. Suppose something strange is going on, such as, your
|
||
|
|
copy of GDB is out of synch, or you have encountered a bug in
|
||
|
|
the C library on your system. (This has happened!) Your copy might
|
||
|
|
crash and ours would not. If you told us to expect a crash, then when
|
||
|
|
ours fails to crash, we would know that the bug was not happening for
|
||
|
|
us. If you had not told us to expect a crash, then we would not be able
|
||
|
|
to draw any conclusion from our observations.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
<A NAME="IDX1331"></A>
|
||
|
|
<A NAME="IDX1332"></A>
|
||
|
|
To collect all this information, you can use a session recording program
|
||
|
|
such as <CODE>script</CODE>, which is available on many Unix systems.
|
||
|
|
Just run your GDB session inside <CODE>script</CODE> and then
|
||
|
|
include the <TT>`typescript'</TT> file with your bug report.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
Another way to record a GDB session is to run GDB
|
||
|
|
inside Emacs and then save the entire buffer to a file.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
<LI>
|
||
|
|
If you wish to suggest changes to the GDB source, send us context
|
||
|
|
diffs. If you even discuss something in the GDB source, refer to
|
||
|
|
it by context, not by line number.
|
||
|
|
<P>
|
||
|
|
|
||
|
|
The line numbers in our development sources will not match those in your
|
||
|
|
sources. Your line numbers would convey no useful information to us.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
</UL>
|
||
|
|
<P>
|
||
|
|
|
||
|
|
Here are some things that are not necessary:
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
<UL>
|
||
|
|
<LI>
|
||
|
|
A description of the envelope of the bug.
|
||
|
|
<P>
|
||
|
|
|
||
|
|
Often people who encounter a bug spend a lot of time investigating
|
||
|
|
which changes to the input file will make the bug go away and which
|
||
|
|
changes will not affect it.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
This is often time consuming and not very useful, because the way we
|
||
|
|
will find the bug is by running a single example under the debugger
|
||
|
|
with breakpoints, not by pure deduction from a series of examples.
|
||
|
|
We recommend that you save your time for something else.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
Of course, if you can find a simpler example to report <EM>instead</EM>
|
||
|
|
of the original one, that is a convenience for us. Errors in the
|
||
|
|
output will be easier to spot, running under the debugger will take
|
||
|
|
less time, and so on.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
However, simplification is not vital; if you do not want to do this,
|
||
|
|
report the bug anyway and send us the entire test case you used.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
<LI>
|
||
|
|
A patch for the bug.
|
||
|
|
<P>
|
||
|
|
|
||
|
|
A patch for the bug does help us if it is a good one. But do not omit
|
||
|
|
the necessary information, such as the test case, on the assumption that
|
||
|
|
a patch is all we need. We might see problems with your patch and decide
|
||
|
|
to fix the problem another way, or we might not understand it at all.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
Sometimes with a program as complicated as GDB it is very hard to
|
||
|
|
construct an example that will make the program follow a certain path
|
||
|
|
through the code. If you do not send us the example, we will not be able
|
||
|
|
to construct one, so we will not be able to verify that the bug is fixed.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
And if we cannot understand what bug you are trying to fix, or why your
|
||
|
|
patch should be an improvement, we will not install it. A test case will
|
||
|
|
help us to understand.
|
||
|
|
</P><P>
|
||
|
|
|
||
|
|
<LI>
|
||
|
|
A guess about what the bug is or what it depends on.
|
||
|
|
<P>
|
||
|
|
|
||
|
|
Such guesses are usually wrong. Even we cannot guess right about such
|
||
|
|
things without first using the debugger to find the facts.
|
||
|
|
</UL>
|
||
|
|
<P>
|
||
|
|
|
||
|
|
<A NAME="Command Line Editing"></A>
|
||
|
|
<HR SIZE="6">
|
||
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
||
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_27.html#SEC654"> << </A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_28.html#SEC657"> >> </A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb.html#SEC_Top">Top</A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_toc.html#SEC_Contents">Contents</A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_38.html#SEC764">Index</A>]</TD>
|
||
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdb_abt.html#SEC_About"> ? </A>]</TD>
|
||
|
|
</TR></TABLE>
|
||
|
|
<BR>
|
||
|
|
<FONT SIZE="-1">
|
||
|
|
|
||
|
|
<address>
|
||
|
|
|
||
|
|
<p>Please send FSF & GNU inquiries & questions to <a
|
||
|
|
href="mailto:gnu@gnu.org">gnu@gnu.org</a>. There are also <a
|
||
|
|
href="http://www.gnu.org/home.html#ContactInfo">other ways to
|
||
|
|
contact</a> the FSF.</p>
|
||
|
|
|
||
|
|
<p>These pages are maintained by <a
|
||
|
|
href="http://www.gnu.org/software/gdb/">the GDB developers</a>.</p>
|
||
|
|
|
||
|
|
<p>Copyright Free Software Foundation, Inc., 59 Temple Place - Suite
|
||
|
|
330, Boston, MA 02111, USA.</p>
|
||
|
|
|
||
|
|
<p>Verbatim copying and distribution of this entire article is
|
||
|
|
permitted in any medium, provided this notice is preserved.</p>
|
||
|
|
|
||
|
|
</address>
|
||
|
|
|
||
|
|
This document was generated
|
||
|
|
by <I>GDB Administrator</I> on <I>March, 27 2008</I>
|
||
|
|
using <A HREF="http://www.mathematik.uni-kl.de/~obachman/Texi2html
|
||
|
|
"><I>texi2html</I></A>
|
||
|
|
|
||
|
|
</BODY>
|
||
|
|
</HTML>
|