- removed comment
Carpet fails when running qc0-mclachlan.par
Issue #751
closed
this is due to ggf::transfer_from_all line 613 (dst->transfer_from) where dst is NULL:
03 assert (lc1>=0 or lc2>=0);
604
605 // Source and destination data
606 gdata * const dst =
607 lc1>=0 ? storage.AT(ml1).AT(rl1).AT(lc1).AT(tl1) : NULL;
608 cdata const & srcs = srcstorage.AT(ml2).AT(rl2);
609 for (int i=0; i<(int)gsrcs.size(); ++i) {
610 gsrcs.AT(i) = lc2>=0 ? srcs.AT(lc2).AT(tl2s.AT(i)) : NULL;
611 }
612
613 dst->transfer_from
614 (state, gsrcs, times, recv, send, slabinfo, p1, p2, time, pos, pot);
which causes a segfault in line 613. lc1 is -1 in this case and passes the assert in line 603. Since dst is used as a pointer it may never be NULL.
It can be reproduced with the qc0-mclachlan.par example from simfactory. Tested on Caltech's bethe workstation with 12 MPI processes and no OpenMP.
hg blames commit 5418b354a3ab which seems to be the original Carpet import into mercurial so this seems to be caused by something else.
Keyword:
Comments (5)
-
reporter
-
- removed comment
gdata.cc has three assert statements checking aligned-ness near the segfault. These are not necessary (debugging leftovers) and should be removed.
-
reporter
- removed comment
Thank you for the quick help, Erik. Removing the three is_aligned asserts helped. I have surrounded the asserts with an "if (is_dst)" which should prevent any NULL pointer references at this point. What had me confused was that the member function was called with a NULL "this" pointer. Is this strictly valid C++ or just "works on all known compilers"?
-
reporter
- changed status to resolved
- removed comment
-
reporter
- edited description
- changed status to closed
- Log in to comment
the segfault goes away if I back out of a2fdf2776631 though looking at transfer_from_all it still seems possible to end up with a NULL dst pointer if lc1==-1 (which was what happened).
Backtrace from where the error occures (this is with -O0, does anyone know why it still has variables optimized out?):