You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by "Martin Sebor (JIRA)" <ji...@apache.org> on 2006/02/02 03:23:43 UTC
[jira] Created: (STDCXX-131) SIGSEGV in std::stable_partition() due
to double destruction
SIGSEGV in std::stable_partition() due to double destruction
------------------------------------------------------------
Key: STDCXX-131
URL: http://issues.apache.org/jira/browse/STDCXX-131
Project: C++ Standard Library
Type: Bug
Components: 25. Algorithms
Versions: 4.1.2, 4.1.3
Environment: all
Reporter: Martin Sebor
Fix For: 4.1.4
>From http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200601.mbox/%3c43DA43F0.9020601@moscow.vdiweb.com%3e:
-------- Original Message --------
Subject: Re: Re: test for lib.alg.partitions
Date: Fri, 27 Jan 2006 19:01:52 +0300
From: Anton Pevtsov <an...@moscow.vdiweb.com>
Reply-To: stdcxx-dev@incubator.apache.org
To: stdcxx-dev@incubator.apache.org
...
Martin Sebor wrote:
> It's certainly possible that there is a bug in the algorithm, but I
> would be more inclined to suspect the test before the algorithm just
> because you just made making non-trivial changes to it.
[...]
> A simple test case would be helpful.
The old test version didn't exercise all possible cases. I updated the
test according to your notes and got the same results. So I still
suspect the bug in the algorithm.
The attached file stable_partition_test.cpp illustrates the problem:
the algorithm fails when the predicate returns true for any element.
I debug the algorithm and found the following code in algorithm.cc, line
760:
...
_Dist __fill = 0;
const _BidirIter __res =
__stable_partition_adaptive (__first, __last, __pred, __dist,
__pair.first, __pair.second,
__fill, (_TypeT*)0);
for (_TypeT *__ptr = __pair.first + __fill; !(__pair.first ==
--__ptr); )
(*__ptr).~_TypeT ();
...
If the __fill remains equal to 0 after the __stable_partition_adaptive
call the "for" will never end and will try to call destructors of
non-existing elements moving from the left bound of the given sequence
to left. Also if __fill is equal to 1 no destructors will be called, but
one should be, shouldn't it?
May be, something like this
...
for (_TypeT *__ptr = __pair.first + __fill; !(__pair.first ==
__ptr--); )
(*__ptr).~_TypeT ();
...
will fix the issue?
And I have another question: what will happen with the temporary buffer
in stable_partition if the X copy ctor throws an exception? It looks
like the buffer will leak.
With best wishes,
Anton Pevtsov
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (STDCXX-131) SIGSEGV in std::stable_partition()
due to double destruction
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Sebor resolved STDCXX-131.
---------------------------------
Resolution: Fixed
Resolved as Fixed, leaving open until a test is added to the regression test suite.
> SIGSEGV in std::stable_partition() due to double destruction
> ------------------------------------------------------------
>
> Key: STDCXX-131
> URL: https://issues.apache.org/jira/browse/STDCXX-131
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 25. Algorithms
> Affects Versions: 4.1.3, 4.1.2
> Environment: all
> Reporter: Martin Sebor
> Assigned To: Martin Sebor
> Fix For: 4.2
>
>
> From http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200601.mbox/%3c43DA43F0.9020601@moscow.vdiweb.com%3e:
> -------- Original Message --------
> Subject: Re: Re: test for lib.alg.partitions
> Date: Fri, 27 Jan 2006 19:01:52 +0300
> From: Anton Pevtsov <an...@moscow.vdiweb.com>
> Reply-To: stdcxx-dev@incubator.apache.org
> To: stdcxx-dev@incubator.apache.org
> ...
> Martin Sebor wrote:
> > It's certainly possible that there is a bug in the algorithm, but I
> > would be more inclined to suspect the test before the algorithm just
> > because you just made making non-trivial changes to it.
> [...]
> > A simple test case would be helpful.
> The old test version didn't exercise all possible cases. I updated the
> test according to your notes and got the same results. So I still
> suspect the bug in the algorithm.
> The attached file stable_partition_test.cpp illustrates the problem:
> the algorithm fails when the predicate returns true for any element.
> I debug the algorithm and found the following code in algorithm.cc, line
> 760:
> ...
> _Dist __fill = 0;
> const _BidirIter __res =
> __stable_partition_adaptive (__first, __last, __pred, __dist,
> __pair.first, __pair.second,
> __fill, (_TypeT*)0);
> for (_TypeT *__ptr = __pair.first + __fill; !(__pair.first ==
> --__ptr); )
> (*__ptr).~_TypeT ();
> ...
> If the __fill remains equal to 0 after the __stable_partition_adaptive
> call the "for" will never end and will try to call destructors of
> non-existing elements moving from the left bound of the given sequence
> to left. Also if __fill is equal to 1 no destructors will be called, but
> one should be, shouldn't it?
> May be, something like this
> ...
> for (_TypeT *__ptr = __pair.first + __fill; !(__pair.first ==
> __ptr--); )
> (*__ptr).~_TypeT ();
> ...
> will fix the issue?
> And I have another question: what will happen with the temporary buffer
> in stable_partition if the X copy ctor throws an exception? It looks
> like the buffer will leak.
> With best wishes,
> Anton Pevtsov
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-131) SIGSEGV in std::stable_partition()
due to double destruction
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Sebor reassigned STDCXX-131:
-----------------------------------
Assignee: Martin Sebor (was: Anton Pevtsov)
> SIGSEGV in std::stable_partition() due to double destruction
> ------------------------------------------------------------
>
> Key: STDCXX-131
> URL: https://issues.apache.org/jira/browse/STDCXX-131
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 25. Algorithms
> Affects Versions: 4.1.3, 4.1.2
> Environment: all
> Reporter: Martin Sebor
> Assigned To: Martin Sebor
> Fix For: 4.2
>
>
> From http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200601.mbox/%3c43DA43F0.9020601@moscow.vdiweb.com%3e:
> -------- Original Message --------
> Subject: Re: Re: test for lib.alg.partitions
> Date: Fri, 27 Jan 2006 19:01:52 +0300
> From: Anton Pevtsov <an...@moscow.vdiweb.com>
> Reply-To: stdcxx-dev@incubator.apache.org
> To: stdcxx-dev@incubator.apache.org
> ...
> Martin Sebor wrote:
> > It's certainly possible that there is a bug in the algorithm, but I
> > would be more inclined to suspect the test before the algorithm just
> > because you just made making non-trivial changes to it.
> [...]
> > A simple test case would be helpful.
> The old test version didn't exercise all possible cases. I updated the
> test according to your notes and got the same results. So I still
> suspect the bug in the algorithm.
> The attached file stable_partition_test.cpp illustrates the problem:
> the algorithm fails when the predicate returns true for any element.
> I debug the algorithm and found the following code in algorithm.cc, line
> 760:
> ...
> _Dist __fill = 0;
> const _BidirIter __res =
> __stable_partition_adaptive (__first, __last, __pred, __dist,
> __pair.first, __pair.second,
> __fill, (_TypeT*)0);
> for (_TypeT *__ptr = __pair.first + __fill; !(__pair.first ==
> --__ptr); )
> (*__ptr).~_TypeT ();
> ...
> If the __fill remains equal to 0 after the __stable_partition_adaptive
> call the "for" will never end and will try to call destructors of
> non-existing elements moving from the left bound of the given sequence
> to left. Also if __fill is equal to 1 no destructors will be called, but
> one should be, shouldn't it?
> May be, something like this
> ...
> for (_TypeT *__ptr = __pair.first + __fill; !(__pair.first ==
> __ptr--); )
> (*__ptr).~_TypeT ();
> ...
> will fix the issue?
> And I have another question: what will happen with the temporary buffer
> in stable_partition if the X copy ctor throws an exception? It looks
> like the buffer will leak.
> With best wishes,
> Anton Pevtsov
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-131) SIGSEGV in std::stable_partition()
due to double destruction
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/STDCXX-131?page=comments#action_12364912 ]
Martin Sebor commented on STDCXX-131:
-------------------------------------
Here's a small test case:
$ cat t.cpp && make t && ./t || /usr/local/gdb-6.3/bin/gdb -q t core
#include <algorithm>
#include <cassert>
static int n;
struct X {
X (): i (++n) { }
X (const X&): i (++n) { }
~X () {
assert (0 != n);
i = 0;
}
int i;
};
bool pred (X&) { return true; }
int main () {
X x [2];
std::stable_partition (x, x + 2, pred);
}
gcc -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG -pthreads -D_RWSTD_USE_CONFIG -I/build/sebor/gcc-4.0.2-15s/include -I/build/sebor/dev/stdlib/include -I/build/sebor/dev/stdlib/../rwtest -I/build/sebor/dev/stdlib/../rwtest/include -I/build/sebor/dev/stdlib/tests/include -pedantic -nostdinc++ -g -W -Wall -Wextra -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long t.cpp
gcc t.o -o t -L/build/sebor/gcc-4.0.2-15s/rwtest -lrwtest15s -pthreads -L/build/sebor/gcc-4.0.2-15s/lib -lstd15s -lsupc++ -lm
Assertion failed: 0 != n, file t.cpp, line 10
Abort (core dumped)
Core was generated by `./t'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/lib/libm.so.1...done.
Loaded symbols for /usr/lib/libm.so.1
Reading symbols from /usr/lib/libpthread.so.1...done.
Loaded symbols for /usr/lib/libpthread.so.1
Reading symbols from /usr/lib/libc.so.1...done.
Loaded symbols for /usr/lib/libc.so.1
Reading symbols from /usr/lib/libdl.so.1...done.
Loaded symbols for /usr/lib/libdl.so.1
Reading symbols from /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1...done.
Loaded symbols for /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1
Reading symbols from /usr/lib/libthread.so.1...done.
Loaded symbols for /usr/lib/libthread.so.1
#0 0xff31ca78 in _lwp_kill () from /usr/lib/libc.so.1
(gdb) where
#0 0xff31ca78 in _lwp_kill () from /usr/lib/libc.so.1
#1 0xff2cbad4 in raise () from /usr/lib/libc.so.1
#2 0xff2b5698 in abort () from /usr/lib/libc.so.1
#3 0xff2b5938 in _assert () from /usr/lib/libc.so.1
#4 0x00049194 in ~X (this=0xa2c48) at t.cpp:10
#5 0x0004a018 in std::__stable_partition<X*, bool (*)(X&), X, int> (
__first=0xffbffb10, __last=0xffbffb18, __pred=0x23210 <pred(X&)>)
at algorithm.cc:770
#6 0x0004a0a0 in std::stable_partition<X*, bool (*)(X&)> (__first=0xffbffb10,
__last=0xffbffb18, __pred=0x23210 <pred(X&)>) at algorithm:703
#7 0x000232a0 in main () at t.cpp:21
> SIGSEGV in std::stable_partition() due to double destruction
> ------------------------------------------------------------
>
> Key: STDCXX-131
> URL: http://issues.apache.org/jira/browse/STDCXX-131
> Project: C++ Standard Library
> Type: Bug
> Components: 25. Algorithms
> Versions: 4.1.2, 4.1.3
> Environment: all
> Reporter: Martin Sebor
> Fix For: 4.1.4
>
> From http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200601.mbox/%3c43DA43F0.9020601@moscow.vdiweb.com%3e:
> -------- Original Message --------
> Subject: Re: Re: test for lib.alg.partitions
> Date: Fri, 27 Jan 2006 19:01:52 +0300
> From: Anton Pevtsov <an...@moscow.vdiweb.com>
> Reply-To: stdcxx-dev@incubator.apache.org
> To: stdcxx-dev@incubator.apache.org
> ...
> Martin Sebor wrote:
> > It's certainly possible that there is a bug in the algorithm, but I
> > would be more inclined to suspect the test before the algorithm just
> > because you just made making non-trivial changes to it.
> [...]
> > A simple test case would be helpful.
> The old test version didn't exercise all possible cases. I updated the
> test according to your notes and got the same results. So I still
> suspect the bug in the algorithm.
> The attached file stable_partition_test.cpp illustrates the problem:
> the algorithm fails when the predicate returns true for any element.
> I debug the algorithm and found the following code in algorithm.cc, line
> 760:
> ...
> _Dist __fill = 0;
> const _BidirIter __res =
> __stable_partition_adaptive (__first, __last, __pred, __dist,
> __pair.first, __pair.second,
> __fill, (_TypeT*)0);
> for (_TypeT *__ptr = __pair.first + __fill; !(__pair.first ==
> --__ptr); )
> (*__ptr).~_TypeT ();
> ...
> If the __fill remains equal to 0 after the __stable_partition_adaptive
> call the "for" will never end and will try to call destructors of
> non-existing elements moving from the left bound of the given sequence
> to left. Also if __fill is equal to 1 no destructors will be called, but
> one should be, shouldn't it?
> May be, something like this
> ...
> for (_TypeT *__ptr = __pair.first + __fill; !(__pair.first ==
> __ptr--); )
> (*__ptr).~_TypeT ();
> ...
> will fix the issue?
> And I have another question: what will happen with the temporary buffer
> in stable_partition if the X copy ctor throws an exception? It looks
> like the buffer will leak.
> With best wishes,
> Anton Pevtsov
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (STDCXX-131) SIGSEGV in std::stable_partition()
due to double destruction
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/STDCXX-131?page=all ]
Martin Sebor reassigned STDCXX-131:
-----------------------------------
Assign To: Anton Pevtsov
Assigned to the original reporter.
> SIGSEGV in std::stable_partition() due to double destruction
> ------------------------------------------------------------
>
> Key: STDCXX-131
> URL: http://issues.apache.org/jira/browse/STDCXX-131
> Project: C++ Standard Library
> Type: Bug
> Components: 25. Algorithms
> Versions: 4.1.2, 4.1.3
> Environment: all
> Reporter: Martin Sebor
> Assignee: Anton Pevtsov
> Fix For: 4.1.4
>
> From http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200601.mbox/%3c43DA43F0.9020601@moscow.vdiweb.com%3e:
> -------- Original Message --------
> Subject: Re: Re: test for lib.alg.partitions
> Date: Fri, 27 Jan 2006 19:01:52 +0300
> From: Anton Pevtsov <an...@moscow.vdiweb.com>
> Reply-To: stdcxx-dev@incubator.apache.org
> To: stdcxx-dev@incubator.apache.org
> ...
> Martin Sebor wrote:
> > It's certainly possible that there is a bug in the algorithm, but I
> > would be more inclined to suspect the test before the algorithm just
> > because you just made making non-trivial changes to it.
> [...]
> > A simple test case would be helpful.
> The old test version didn't exercise all possible cases. I updated the
> test according to your notes and got the same results. So I still
> suspect the bug in the algorithm.
> The attached file stable_partition_test.cpp illustrates the problem:
> the algorithm fails when the predicate returns true for any element.
> I debug the algorithm and found the following code in algorithm.cc, line
> 760:
> ...
> _Dist __fill = 0;
> const _BidirIter __res =
> __stable_partition_adaptive (__first, __last, __pred, __dist,
> __pair.first, __pair.second,
> __fill, (_TypeT*)0);
> for (_TypeT *__ptr = __pair.first + __fill; !(__pair.first ==
> --__ptr); )
> (*__ptr).~_TypeT ();
> ...
> If the __fill remains equal to 0 after the __stable_partition_adaptive
> call the "for" will never end and will try to call destructors of
> non-existing elements moving from the left bound of the given sequence
> to left. Also if __fill is equal to 1 no destructors will be called, but
> one should be, shouldn't it?
> May be, something like this
> ...
> for (_TypeT *__ptr = __pair.first + __fill; !(__pair.first ==
> __ptr--); )
> (*__ptr).~_TypeT ();
> ...
> will fix the issue?
> And I have another question: what will happen with the temporary buffer
> in stable_partition if the X copy ctor throws an exception? It looks
> like the buffer will leak.
> With best wishes,
> Anton Pevtsov
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (STDCXX-131) SIGSEGV in std::stable_partition() due
to double destruction
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/STDCXX-131?page=all ]
Martin Sebor updated STDCXX-131:
--------------------------------
Fix Version: 4.2
(was: 4.1.4)
> SIGSEGV in std::stable_partition() due to double destruction
> ------------------------------------------------------------
>
> Key: STDCXX-131
> URL: http://issues.apache.org/jira/browse/STDCXX-131
> Project: C++ Standard Library
> Type: Bug
> Components: 25. Algorithms
> Versions: 4.1.2, 4.1.3
> Environment: all
> Reporter: Martin Sebor
> Assignee: Anton Pevtsov
> Fix For: 4.2
>
> From http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200601.mbox/%3c43DA43F0.9020601@moscow.vdiweb.com%3e:
> -------- Original Message --------
> Subject: Re: Re: test for lib.alg.partitions
> Date: Fri, 27 Jan 2006 19:01:52 +0300
> From: Anton Pevtsov <an...@moscow.vdiweb.com>
> Reply-To: stdcxx-dev@incubator.apache.org
> To: stdcxx-dev@incubator.apache.org
> ...
> Martin Sebor wrote:
> > It's certainly possible that there is a bug in the algorithm, but I
> > would be more inclined to suspect the test before the algorithm just
> > because you just made making non-trivial changes to it.
> [...]
> > A simple test case would be helpful.
> The old test version didn't exercise all possible cases. I updated the
> test according to your notes and got the same results. So I still
> suspect the bug in the algorithm.
> The attached file stable_partition_test.cpp illustrates the problem:
> the algorithm fails when the predicate returns true for any element.
> I debug the algorithm and found the following code in algorithm.cc, line
> 760:
> ...
> _Dist __fill = 0;
> const _BidirIter __res =
> __stable_partition_adaptive (__first, __last, __pred, __dist,
> __pair.first, __pair.second,
> __fill, (_TypeT*)0);
> for (_TypeT *__ptr = __pair.first + __fill; !(__pair.first ==
> --__ptr); )
> (*__ptr).~_TypeT ();
> ...
> If the __fill remains equal to 0 after the __stable_partition_adaptive
> call the "for" will never end and will try to call destructors of
> non-existing elements moving from the left bound of the given sequence
> to left. Also if __fill is equal to 1 no destructors will be called, but
> one should be, shouldn't it?
> May be, something like this
> ...
> for (_TypeT *__ptr = __pair.first + __fill; !(__pair.first ==
> __ptr--); )
> (*__ptr).~_TypeT ();
> ...
> will fix the issue?
> And I have another question: what will happen with the temporary buffer
> in stable_partition if the X copy ctor throws an exception? It looks
> like the buffer will leak.
> With best wishes,
> Anton Pevtsov
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira