| Message ID | 20141104043400.GJ3961@redhat.com |
|---|---|
| State | New |
| Headers | show |
Hi again, On 11/04/2014 05:34 AM, Jonathan Wakely wrote: > On 04/11/14 03:41 +0000, Jonathan Wakely wrote: >> On 03/11/14 22:07 +0000, Jonathan Wakely wrote: >>> On 3 November 2014 17:51, Paolo Carlini <paolo.carlini@oracle.com> >>> wrote: >>>> .. other than the above issue, I see a segmentation fault for: >>>> >>>> performance/ext/pb_ds/multimap_text_insert_mem_large.cc Not a big deal of course, but unfortunately today I'm seeing *two* segfaults for pb_ds: performance/ext/pb_ds/multimap_text_insert_mem_large.cc .../libstdc++-v3/scripts/check_performance: line 41: 16173 Segmentation fault ./$EXE_NAME &>tmp.$FILE_NAME performance/ext/pb_ds/multimap_text_insert_mem_small.cc .../libstdc++-v3/scripts/check_performance: line 41: 16217 Segmentation fault ./$EXE_NAME &>tmp.$FILE_NAME Paolo.
.. and also: performance/ext/pb_ds/priority_queue_text_pop_mem.cc .../libstdc++-v3/scripts/check_performance: line 41: 16905 Segmentation fault ./$EXE_NAME &>tmp.$FILE_NAME Paolo.
On 4 November 2014 13:13, Paolo Carlini <paolo.carlini@oracle.com> wrote: > Hi again, > > > On 11/04/2014 05:34 AM, Jonathan Wakely wrote: >> >> On 04/11/14 03:41 +0000, Jonathan Wakely wrote: >>> >>> On 03/11/14 22:07 +0000, Jonathan Wakely wrote: >>>> >>>> On 3 November 2014 17:51, Paolo Carlini <paolo.carlini@oracle.com> >>>> wrote: >>>>> >>>>> .. other than the above issue, I see a segmentation fault for: >>>>> >>>>> performance/ext/pb_ds/multimap_text_insert_mem_large.cc > > Not a big deal of course, but unfortunately today I'm seeing *two* segfaults > for pb_ds: > > performance/ext/pb_ds/multimap_text_insert_mem_large.cc > .../libstdc++-v3/scripts/check_performance: line 41: 16173 Segmentation > fault ./$EXE_NAME &>tmp.$FILE_NAME > performance/ext/pb_ds/multimap_text_insert_mem_small.cc > .../libstdc++-v3/scripts/check_performance: line 41: 16217 Segmentation > fault ./$EXE_NAME &>tmp.$FILE_NAME They were both caused by the infinite recursion in the operator== for tracker_allocator, which should be fixed. However, my change to std::deque's move constructor introduced some new failures, mostly due to dg-error line numbers that need to change, but one real failure in 23_containers/deque/allocator/move_assign.cc I'm not sure whether the right approach is to violate the requirement that deque's move constructor move constructs the allocator, (which I changed to copy construction, to meet the exception safety guarantee that the RHS of the move construction maintains its invariants) or to change the invariant so that a deque doesn't always have a map allocated. I'll fix it asap.
Hi, On 11/04/2014 04:32 PM, Jonathan Wakely wrote: > Not a big deal of course, but unfortunately today I'm seeing *two* segfaults > for pb_ds: > > performance/ext/pb_ds/multimap_text_insert_mem_large.cc > .../libstdc++-v3/scripts/check_performance: line 41: 16173 Segmentation > fault ./$EXE_NAME &>tmp.$FILE_NAME > performance/ext/pb_ds/multimap_text_insert_mem_small.cc > .../libstdc++-v3/scripts/check_performance: line 41: 16217 Segmentation > fault ./$EXE_NAME &>tmp.$FILE_NAME > They were both caused by the infinite recursion in the operator== for > tracker_allocator, which should be fixed. To be clear, I see (deterministically, apparently) the three pb_ds fails which I reported earlier today with a *current* tree. But the pb_ds issues are definitely low priority, unless they point to something serious elsewhere. Thanks for looking into that. Paolo.
On 11/04/2014 04:46 PM, Paolo Carlini wrote: > Hi, > > On 11/04/2014 04:32 PM, Jonathan Wakely wrote: >> Not a big deal of course, but unfortunately today I'm seeing *two* >> segfaults >> for pb_ds: >> >> performance/ext/pb_ds/multimap_text_insert_mem_large.cc >> .../libstdc++-v3/scripts/check_performance: line 41: 16173 Segmentation >> fault ./$EXE_NAME &>tmp.$FILE_NAME >> performance/ext/pb_ds/multimap_text_insert_mem_small.cc >> .../libstdc++-v3/scripts/check_performance: line 41: 16217 Segmentation >> fault ./$EXE_NAME &>tmp.$FILE_NAME >> They were both caused by the infinite recursion in the operator== for >> tracker_allocator, which should be fixed. > To be clear, I see (deterministically, apparently) the three pb_ds > fails which I reported earlier today with a *current* tree. But the > pb_ds issues are definitely low priority, unless they point to > something serious elsewhere. Thanks for looking into that. Ah! The testsuite_allocator.h fix of yours is still unapplied, didn't know that, sorry ;) Paolo.
On 4 November 2014 16:34, Paolo Carlini wrote: > Ah! The testsuite_allocator.h fix of yours is still unapplied, didn't know > that, sorry ;) My bad - I thought I'd committed it! Done now.
commit 75a3f132da320a76baf7e82f4f850cdfce239a2e
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Tue Nov 4 04:33:32 2014 +0000
* testsuite/util/testsuite_allocator.h (operator==): Fix recursion.
diff --git a/libstdc++-v3/testsuite/util/testsuite_allocator.h b/libstdc++-v3/testsuite/util/testsuite_allocator.h
index 8edc0a5..dec8d1a 100644
--- a/libstdc++-v3/testsuite/util/testsuite_allocator.h
+++ b/libstdc++-v3/testsuite/util/testsuite_allocator.h
@@ -209,7 +209,7 @@ namespace __gnu_test
{
const Alloc1& alloc1 = lhs;
const Alloc2& alloc2 = rhs;
- return lhs == rhs;
+ return alloc1 == alloc2;
}
template<class T1, class Alloc1, class T2, class Alloc2>