#768 testgenericfem failes
Metadata
| Property | Value |
|---|---|
| Reported by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Reported at | Apr 8, 2010 12:59 |
| Type | Bug Report |
| Version | 1.2 |
| Operating System | Unspecified / All |
| Last edited by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Last edited at | Mar 8, 2011 17:38 |
| Closed by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Closed at | Mar 8, 2011 17:38 |
| Closed in version | 2.2 |
| Resolution | Fixed |
| Comment |
Description
I tested the release 2.0 branch.
This needs to be fixed before the release.
Activity
christi@sansibar:~/DuneRelease/localfunctions/dune/localfunctions/test$ ./testgenericfem Testing LagrangeLocalFiniteElement on 3d simplex elements with double precision order : 1 order : 2 order : 3 order : 4 order : 5 order : 6 Testing LagrangeLocalFiniteElement on 2d cube elements with double precision order : 1 order : 2 order : 3 order : 4 Testing LagrangeLocalFiniteElement on 2d simplex elements with higher precision order : 5 Segmentation fault
-
The debugger states that the problem is in
Program received signal SIGSEGV, Segmentation fault. _int_malloc (av=0xb7e1e3c0, bytes=40) at malloc.c:4300 4300 malloc.c: No such file or directory. in malloc.c (gdb) up #1 (closed) 0xb7d4a1ae in *__GI___libc_malloc (bytes=40) at malloc.c:3660 3660 in malloc.c (gdb) up #2 (closed) 0xb7f5ba52 in __gmp_default_allocate () from /usr/lib/libgmp.so.3
I'm not sure if this is a bug in my libgmp, in localfunctions or in dune-common. Could someone else give it a try?
Martin Drohmann (mdrohmann@uni-muenster.de) commented on the issue:
The trunk version also compiles for my test system (gcc-4.2 with strict aliasing)
However, I remembered that testgenericfem also failed on the trunk with the same segfault before Andreas' patches 843-846. I thought that I checked the release afterwards, too. But obviously not careful enough, as the release still segfaults.
I will try to find out, which patch in the trunk removes the segfault. This should be in dune-common somewhere...
-
Martin Drohmann (mdrohmann@uni-muenster.de) commented on the issue:
Okay, this was quite easy: Merging patch 5926 in dune-common from trunk to the release branch, prevents testgenericfem from segfaulting.
But I do not understand, why. Maybe you two who have more insight can decide wether the patch really is a bugfix and then merge it to the release branch?
Actually the test failed with multi-precision types (gmp or alglib or similar). The patch you mentioned replaces the use of stc::memcpy in the copy constructor and the assignment operator of the FieldVector with a for loop.
If you think about it, it is not surprising that memcpy() causes problems with multi-precision types: these types can often be arbitrary precision, so they cannot store all data in the object itself. Instead, the must allocate some memory and store a pointer to that memory in the object. memcpy() does a shallow copy; it will copy the pointer, but it won't duplicate the pointed to data. Now you have to pointers pointing to the same region of memory with two objects feeling resonsible to free that memory when they are done, leading to a use-after-free or a double-free error. In addition, the object that was assigned to may have already allocated some memory but the pointer was overwritten so that memory cannot be freed anymore, leading to a memory leak.
-
Martin Drohmann (mdrohmann@uni-muenster.de) commented on the issue:
I checked again, with current 2.0 branch for all dune core modules, and I cannot reproduce the problem on my workstation, not even the valgrind error.
BUT: On the netbook of my colleague (a 32 bit computer), the test segfaults. Do you also have a 32 bit system, Christian? Maybe, the segfault is related to the processor architecture.
-
Martin Drohmann (mdrohmann@uni-muenster.de) commented on the issue:
Here is the backtrace...
Attachments
-
I'm getting the impression that the matrix classes used in the generic-fem stuff are somewhat broken.
Have a look at coeffmatrix.hh, lines 240-245 and 199-204. The skip_ vector is allocated with size+1, but is only initialized till skip_[size-1]. The last entry is unitialized and might thus be removed. But if I change the allocated size to size, I obtain a valgrind error "Invalid read of size 4" in Dune::SparseCoeffMatrix::mult (line 122)
Christian
