#493 test failure: dune-common/common/test/sllisttest

doesn't seem to be a problem with the compiler. originally compiled with gcc 4.3.3, still happens with 4.4.0, snapshot from 20090130.

This is probably an issue with the poolallocator. Could you please try the newest version of dune-common again.

I'm on r5420 and the problem is still there.

This may be a duplicate of 377.

The problem persists w/ 1.2.1 on a current amd64 system[*].

@sander: did you mean a different bug by any chance? The title of bug #377 (closed) is "WebSVN for grid-dev-howto buggy".

[*] linux 2.6.31-rc8, g++ 4.4.1

You're right, I certainly didn't mean 377... I don't remember which one I meant, though. Sorry!

Is there I chance I can get access to the machine in question to see what's happening?

Here is a reduced testcase. Still long though, but I won't continue reducing tonight.

This really is a PoolAllocator issue. I'd close it as a duplicate of 491 if it wasn't for the different set of compiler flags used there.

#include<dune/common/poolallocator.hh> #include

#include

typedef Dune::PoolAllocator<int,8*1024-16> IntAllocator;

struct Element { Element* next_; int item_;

Element() : next_(0), item_() {}

};

template struct SLList {

SLList()
    : tail_(&beforeHead_)
{
    beforeHead_.next_=0;
}

Element beforeHead_;

Element* tail_;

};

int main() { typedef IntAllocator TheAllocator; //typedef std::allocator TheAllocator;

SLList<int>  alist;

/** @brief Pseudo element before the first entry. */
TheAllocator::rebind<Element>::other allocator_;

//alist.push_back(1);
int item = 1;
alist.tail_->next_ = allocator_.allocate(1, 0);
alist.tail_ = alist.tail_->next_;
::new (static_cast<void*>(&(alist.tail_->item_))) int(item);
alist.tail_->next_=0;
assert(alist.tail_->next_==0);

//if(*(alist.begin())!=1) {
assert(alist.beforeHead_.next_->item_ == 1);

//alist.push_front(3);
item = 3;
if(alist.tail_ == &alist.beforeHead_){
    // list was empty
    alist.beforeHead_.next_ = alist.tail_ = allocator_.allocate(1, 0);
    ::new(static_cast<void*>(&alist.beforeHead_.next_->item_)) int(item);
    alist.beforeHead_.next_->next_=0;
}else{
    Element* added = allocator_.allocate(1, 0);
    ::new(static_cast<void*>(&added->item_)) int(item);
    added->next_=alist.beforeHead_.next_;
    alist.beforeHead_.next_=added;
}
assert(alist.tail_->next_==0);

//if(*(alist.begin())!=3){
assert(alist.beforeHead_.next_->item_ == 3);

//alist.pop_front();
assert(alist.beforeHead_.next_);
Element* next = alist.beforeHead_.next_;

// deleting last element changes tail!
if(next == alist.tail_)
    alist.tail_ = &alist.beforeHead_;

alist.beforeHead_.next_ = next->next_;
//next->item_.~T();
next->next_ = 0;
allocator_.deallocate(next, 1);

//if(*(alist.begin())!=1){
if (alist.beforeHead_.next_->item_ != 1) {
  std::cerr<<"Entry should be 1, but is "<< alist.beforeHead_.next_->item_ <<"! Push back failed! "<<__FILE__<<":"<<__LINE__<<std::endl;
  assert(false);
}

return 0;

}

This one is really strange. I could reproduce this using gcc 4.1, 4.2, 4.3. Elias told me that he originally saw it just using O2 instead of this weird set of options, but I cannot confirm this.

I tried to reduce the test case further but I didn't get very far (new test case is attached). Seemingly innocent actions make the bug go away. For example, I can remove the assertion in line 51 (which passes), and the bug goes away. Also, when I replace the list object by direct declaration of its data members, the bug goes away.

I am stuck. The test case is still too long to post it as a gcc bug (it still includes poolallocator.hh). Does someone have an idea how to proceed? The test case does the following:

create an empty list
push_back(1)
push_front(3)
pop_front()

Now the first list item should be 1, but this is not so. Instead, apparently unitialized memory is accessed there. If the PoolAllocator is replaced by std::allocator everything works fine.

The platform is Linux andorra 2.6.26-2-amd64 #1 (closed) SMP Wed Aug 19 22:33:18 UTC 2009 x86_64 GNU/Linux

Attachments

fs_493_testcase_a.cc

Elias told me that he originally saw it just using O2 instead of this weird set of options, but I cannot confirm this.

Hm that's weird. I checked out these files from dune common:

alignment.hh deprecated.hh gcd.hh lcm.hh poolallocator.hh static_assert.hh

put them into a directory, removed dune/common from the #includes and compiled your fs_493_testcase_a.cc in there. The result is

pipping@bogus ~/Downloads/dune $ g++ fs_493_testcase_a.cc -I . -O2 pipping@bogus ~/Downloads/dune $ ./a.out a.out: fs_493_testcase_a.cc:65: int main(): Assertion `alist.beforeHead_.next_->item_ == 1' failed. Aborted pipping@bogus ~/Downloads/dune $ g++ fs_493_testcase_a.cc -I . -O1 pipping@bogus ~/Downloads/dune $ ./a.out pipping@bogus ~/Downloads/dune $

pipping@bogus ~/Downloads/dune $ gcc -dumpversion 4.4.1 pipping@bogus ~/Downloads/dune $ gcc -dumpmachine x86_64-pc-linux-gnu pipping@bogus ~/Downloads/dune $

While w/ that reduced test case and -O2 (in contrast to you, apparently) I do get a test failure, I do not get a test failure w/ the original set of flags, -O1 -fgcse -fschedule-insns -fstrict-aliasing -ftree-vrp (again, in contrast to you, no). I'll investigate a bit what combination breaks it.

Strange indeed. I just retried on andorra.mi.fu-berlin.de. I copied the testcase into sllisttest.cc and did

make sllisttest CXXFLAGS=-O2 g++ -std=c++0x -DHAVE_CONFIG_H -I. -I../.. -I../.. -O2 -MT sllisttest.o -MD -MP -MF .deps/sllisttest.Tpo -c -o sllisttest.o sllisttest.cc mv -f .deps/sllisttest.Tpo .deps/sllisttest.Po /bin/sh ../../libtool --tag=CXX --mode=link g++ -std=c++0x -O2 ../../common/libcommon.la -o sllisttest sllisttest.o -lm g++ -std=c++0x -O2 -o sllisttest sllisttest.o ../../common/.libs/libcommon.a -lm

And it works. :-|

Can you confirm that removing the assertion in line 51 solves the problem?

Can you trigger the problem without using the class SLList?

If by line 51 you mean

assert(alist.beforeHead_.next_);

then no, I still get the failure.

The flags necessary to trigger the test failure are

-O1 -fgcse -fschedule-insns -fstrict-aliasing -ftree-vrp

for me. It's possible to get a list of flags that are enabled w/ -O2 but not w/ -O1 this way:

pipping@bogus ~ $ diff -U0 <(g++ -c -Q -O1 --help=optimizers) <(g++ -c -Q -O2 --help=optimizers) | awk '/^+ / { printf "%s ", $2 } END { print "" }' -falign-functions -falign-jumps -falign-labels -falign-loops -fcaller-saves -fcrossjumping -fcse-follow-jumps -fdelete-null-pointer-checks -fexpensive-optimizations -fforward-propagate -fgcse -finline-small-functions -fipa-cp -foptimize-register-move -foptimize-sibling-calls -fpeephole2 -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop -fschedule-insns2 -fstrict-aliasing -fthread-jumps -ftree-builtin-call-dce -ftree-pre -ftree-vrp pipping@bogus ~ $

I see two possible ways to proceed. Either we assume that this is a bug in PoolAllocator. Then we should make the testcase as small as possible without touching PoolAllocator and try to understand where PoolAllocator fails. Or we assume that it is a bug in the compiler /toolchain. Then we have to reduce the testcase even further. I don't really know what to think.

Regarding that problem on andorra, could you trying running make clean again? Something might not have been rebuilt for some reason.

If it is not a compiler bug. Then I would guess that it is most likely that some of the enum calculation in Pool are wrong. (Still I do not understand why the behaviour changes for different compiler flags.

It would be nice if someone with access to to the machine would try the problem with double instead of int and with with a different number as the second template argument (maybe a realy small one).

@Elias: as Markus is the one who knows the PoolAllocator, maybe you could grant him temporary access to your machine?

Here's a makefile to make reproducing the issue a tad easier. Interestingly, on a (somewhat old) ubuntu live cd for amd64, after installing

g++ (Ubuntu 4.3.3-5ubuntu4) 4.3.3

I don't get the error whereas w/

g++ (GCC) 4.4.1

I do

Attachments

Makefile

I forgot to mention that the g++ 4.4.1 was on another system.

I'm a bit confused now -- are bug #493 (closed) and bug #491 (closed) dealing w/ the same issue?

I think so. There is no evidence to suggest that SList itself is buggy. The problems seem to be caused by the use of the PoolAllocator.

Status changed to closed

Property	Value
Reported by	Elias Pipping (elias.pipping@fu-berlin.de)
Reported at	Feb 5, 2009 21:19
Type	Bug Report
Version	Git (pre2.4) [autotools]
Operating System	Linux 64bit
Last edited by	Oliver Sander (oliver.sander@tu-dresden.de)
Last edited at	Dec 3, 2009 13:10
Closed by	Oliver Sander (oliver.sander@tu-dresden.de)
Closed at	Dec 3, 2009 13:10
Closed in version	Unknown
Resolution	Duplicate
Comment	This really is a duplicate of 491.

#493 test failure: dune-common/common/test/sllisttest

Metadata

Description

Designs

Child items ...

Activity

Attachments

Attachments