From: wolf Date: Tue, 7 Feb 2006 00:48:53 +0000 (+0000) Subject: Rewrite. X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=eb47eb9dbca4899a630740a1af9db3ddacd5cf97;p=dealii-svn.git Rewrite. git-svn-id: https://svn.dealii.org/trunk@12245 0785d39b-7218-0410-832d-ea1e28bc413d --- diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/results.html b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/results.html index 40d1b31e3a..57305cf6f7 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/results.html +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/results.html @@ -32,19 +32,20 @@ Cycle 7:

-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: grid-5 - -

@@ -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  in function
-    Subscriptor::~Subscriptor()
-The violated condition was:
+An error occurred in line <78> of file  in function
+    virtual Subscriptor::~Subscriptor()
+The violated condition was: 
     counter == 0
 The name and call sequence of the exception was:
-    InUse()
-Additional Information:
-This object is still used by 1 other objects.
+    ExcInUse(counter, object_info->name(), infostring)
+Additional Information: 
+Object of class 4FE_QILi2EE is still used by 1 other objects.
+  from Subscriber 10DoFHandlerILi2EE
+
+Stacktrace:
+-----------
+#0  /u/bangerth/p/deal.II/1/deal.II/lib/libbase.g.so(_ZN11SubscriptorD2Ev+0x25b) [0x2aaaabc62087]
+#1  /u/bangerth/p/deal.II/1/deal.II/lib/libdeal_II_2d.g.so(_ZN13FiniteElementILi2EED2Ev+0x3f6) [0x2aaaaaf85122]
+#2  ./step-6(_ZN7FE_PolyI24TensorProductPolynomialsILi2EELi2EED2Ev+0x58) [0x41ee28]
+#3  ./step-6(_ZN4FE_QILi2EED1Ev+0x58) [0x41b9ee]
+#4  ./step-6(_ZN14LaplaceProblemILi2EED1Ev+0x10d) [0x4162fb]
+#5  ./step-6(main+0x7d) [0x415da5]
+#6  /lib64/tls/libc.so.6(__libc_start_main+0xea) [0x2aaaac60254a]
+#7  ./step-6(_ZN15DataOut_DoFDataILi2E10DoFHandlerLi2ELi2EE5clearEv+0x52) [0x415c8a]
 --------------------------------------------------------
+make: *** [run] Aborted
 

-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().

-