-As intended, the number of cells roughly doubles in each cycle.
-The number of degrees is slightly more than four times the number of
+As intended, the number of cells roughly doubles in each cycle. The
+number of degrees is slightly more than four times the number of
cells; one would expect a factor of exactly four in two spatial
dimensions on an infinite grid (since the spacing between the degrees
of freedom is half the cell width: one additional degree of freedom on
each edge and one in the middle of each cell), but it is larger than
-that factor due to the finite size and due to additional degrees of
-freedom which are introduced due to hanging nodes and local
+that factor due to the finite size of the mesh and due to additional
+degrees of freedom which are introduced by hanging nodes and local
refinement.
-The final solution, as written by the program, looks as follows:
+The final solution, as written by the program at the end of the
+run() function, looks as follows:
@@ -53,7 +54,7 @@ The final solution, as written by the program, looks as follows:
In each cycle, the program furthermore writes the grid in EPS
-format. These are depicted in the following:
+format. These are shown in the following:
@@ -84,8 +85,6 @@ format. These are depicted in the following:
-
-
@@ -112,107 +111,72 @@ from the optimal square.
-For completeness, we show what happens if the destructor is omitted
+For completeness, we show what happens if the code we commented about
+in the destructor of the LaplaceProblem class is omitted
from this example.
--------------------------------------------------------
-An error occurred in line <20> of file
-From the above error message, it is difficult to infer what has
-actually happened. A stack backtrace in the debugger at least tells us
-what object is presently destructed:
-
-#0 0x4004b0d1 in __kill () at soinit.c:27
-#1 0x4004aeff in raise (sig=6) at ../sysdeps/posix/raise.c:27
-#2 0x4004c19b in abort () at ../sysdeps/generic/abort.c:83
-#3 0x813e2b9 in void __IssueError_Assert (
- file=0x8187223 "source/subscriptor.cc", line=20,
- function=0x8187207 "Subscriptor::~Subscriptor()",
- cond=0x81871fa "counter == 0", exc_name=0x81871f2 "InUse()",
- e={ = { = {_vptr.exception = 0x8189a8c},
- file = 0x8187223 "source/subscriptor.cc", line = 20,
- function = 0x8187207 "Subscriptor::~Subscriptor()",
- cond = 0x81871fa "counter == 0", exc = 0x81871f2 "InUse()"}, })
- at /home/wolf/program/newdeal/deal.II/base/include/base/exceptions.h:382
-#4 0x80daa64 in Subscriptor::~Subscriptor (this=0xbffff534, __in_chrg=2)
- at source/subscriptor.cc:20
-#5 0x8063d57 in FiniteElementBase<2>::~FiniteElementBase (this=0xbffff534,
- __in_chrg=2) at source/fe/fe.cc:256
-#6 0x8063dd5 in FiniteElement<2>::~FiniteElement (this=0xbffff534,
- __in_chrg=2)
- at /home/wolf/program/newdeal/deal.II/deal.II/include/fe/fe.h:967
-#7 0x8074d55 in FEQ1Mapping<2>::~FEQ1Mapping (this=0xbffff534, __in_chrg=2)
- at source/fe/q1_mapping.cc:726
-#8 0x806f625 in FEQ2<2>::~FEQ2 (this=0xbffff534, __in_chrg=2)
- at source/fe/fe_lib.quadratic.cc:1095
-#9 0x80e9d5a in LaplaceProblem<2>::~LaplaceProblem (this=0xbffff084,
- __in_chrg=2) at step-6.cc:306
-#10 0x804a783 in main () at step-6.cc:932
-
-Note that the debugger stops automatically at the point where the
-exception was thrown, you need not place a breakpoint. From frame 4 we
-see that the exception occured in the destructor of the
-``Subscriptor'' class, which is where the zeroness of the counter is
-checked. Frame 8 tells us that it is the ``fe'' object (which is of
-type ``FEQ2'') of the ``LaplaceProblem'' class, that resists its
-destruction.
-
-
-
+From the above error message, we conclude that an object of type
+``10DoFHandlerILi2EE'' is still using the object of type
+``4FE_QILi2EE''. These are of course "mangled" names for
+DoFHandler and FE_Q. The mangling works as
+follows: the first number indicates the number of characters of the
+template class, i.e. 10 for DoFHandler and 4
+forFE_Q; the rest of the text is then template
+arguments. From this we can already glean a little bit who's the
+culprit here, and who the victim.:
The one object that still uses the finite element is the
-``dof_handler'' object. This is usually difficult to find out since
-the ``Subscriptor'' class that stores the counter has no possibility
-to store which other object subscribed to it. However, by thinking a
-little bit about which objects use the one that is presently
-destructed, one usually quite quickly finds out where the problem is.
+``dof_handler'' object.
-
-Versions after deal.II 3.0 give slightly better
-information in that they are at least able to tell which object is
-destructed. The output then looks like this:
-
+The stacktrace gives an indication of where the problem happened. For
+technical reasons, the present code only shows mangled function names,
+but if you run the stacktrace through the c++filt
+program, you will get something like this:
---------------------------------------------------------
-An error occurred in line <20> of file in function
- Subscriptor::~Subscriptor()
-The violated condition was:
- counter == 0
-The name and call sequence of the exception was:
- InUse()
-Additional Information:
-Object of class t4FEQ21i2 is still used by 1 other objects.
---------------------------------------------------------
+#0 /u/bangerth/p/deal.II/1/deal.II/lib/libbase.g.so(Subscriptor::~Subscriptor()+0x25b) [0x2aaaabc62087]
+#1 /u/bangerth/p/deal.II/1/deal.II/lib/libdeal_II_2d.g.so(FiniteElement<2>::~FiniteElement()+0x3f6) [0x2aaaaaf85122]
+#2 ./step-6(FE_Poly, 2>::~FE_Poly()+0x58) [0x41ee28]
+#3 ./step-6(FE_Q<2>::~FE_Q()+0x58) [0x41b9ee]
+#4 ./step-6(LaplaceProblem<2>::~LaplaceProblem()+0x10d) [0x4162fb]
+#5 ./step-6(main+0x7d) [0x415da5]
+#6 /lib64/tls/libc.so.6(__libc_start_main+0xea) [0x2aaaac60254a]
+#7 ./step-6(DataOut_DoFData<2, DoFHandler, 2, 2>::clear()+0x52) [0x415c8a]
-This tells us, that the object that is presently deleted is of type
-t4FEQ21i2. Of course, this is not the actual name of the
-class, but what the C++ run time library returns as name; it is in
-fact the mangled name of the class, and you can get back the
-true class name by running the program c++filt on that
-name, which then returns FEQ2<2>. (The mangled name
-can be read without c++filt in the following way: the
-first letter tells us that the class name is a template, the second
-that the name of the class name without template arguments is four
-characters; we then already have FEQ2<...>. After
-the class name, the next character tells us that the class has one
-template parameter, the ``i'' indicates that it is of type ``int'' and
-finally that it has the value ``2''. Thus, we arrive at
-FEQ2<2>.)
+In other words, we can now see that the exception was triggered in the
+destructor of the FiniteElement class that was called
+through a few more functions from the destructor of the
+LaplaceProblem class, exactly where we have commented out
+the call to DoFHandler::clear().