STLport

Bugs item #1624993, was opened at 2006-12-30 18:38
Message generated for change (Comment added) made by dums
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1624993&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General code
Group: None
>Status: Pending
Resolution: Invalid
Priority: 4
Private: No
Submitted By: WorkerBee (workerbee)
Assigned to: Francois Dumont (dums)
Summary: crash in locale code on multiprocessor system

Initial Comment:

* Platform:     Windows XP Professional, Windows 2003 Server
* Hardware:     Centrino Dual Core, Pentium D Dual Core
* Compiler:     Visual C++ 6.0 Service Pack 6
* STLPort:      Version 5.1.0 final version


We have experienced randomly crashes on our production system after switching
from STLport 4.6.2 to 5.1.0.

After some investigation it boils down to being a problem in the locale code
if used in more than one thread on multiprocessor/dual core systems.

Just creating and destroying some locale objects will crash the program on
multiprocessor/dual core systems after a few seconds only if more than one
thread is running.

I have verified the problem with the vanilla STL from Microsofts VC6 which of
course also crashes because it's known to be buggy.

Running the same program under STLport 4.6.2 shows no problems at all, it runs
without any crashes on these systems.

A have provided a simple test case to reproduce the problem.

Could someone please verify that this is a bug ?

Thanks,

Guenter




----------------------------------------------------------------------

>Comment By: Francois Dumont (dums)
Date: 2007-01-26 22:12

Message:
Logged In: YES 
user_id=1096600
Originator: NO

I agree I have been a little distracted on this point. Thanks for having
report it before 5.1.1 release.

About _Locale_init, you have the source so I am sure you know where it is
called. It is associated to Standard iostreams initialization (cout, cin,
...). It is compiler/platform dependent but you can consider that it is
called at library load time, even before you enter main, so at a
necessarily thread safe moment.

----------------------------------------------------------------------

Comment By: WorkerBee (workerbee)
Date: 2007-01-26 08:42

Message:
Logged In: YES 
user_id=1679913
Originator: YES

Well, maybe it is working, but ...
looking at the sources, I found (diff with previous revision)

Line 1747 
1747 	   if (__FindFlag == 0) return -1;
1748 	  	 
1749 	   *lcid = __FndLCID;
1750 	  	 
1751 	   LeaveCriticalSection(&__criticalSection);
1752 	   return 0;

Line 1747 is interesting, you will never leave the
critical section, which causes a deadlock.

This should be fixed ASAP.

BTW: where does void _Locale_init() get called (in a thread safe way) ?




----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-01-12 21:44

Message:
Logged In: YES 
user_id=1096600
Originator: NO

Fix is now available in 5.1 branch, it will be part of 5.1.1. It would be
great if you could check that it is solving your problems.

----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-01-03 22:10

Message:
Logged In: YES 
user_id=1096600
Originator: NO

Hi

What I find the most surprising in this bug report is that you do not
already have this problem with 4.6. I am working on improvements of
localization support and doing so I discovered several multi-threading
issues in Win32 portage. You can check by yourself in
src\c_locale_win32\c_locale_win32.c, you will find several static variables
that are the source of the bugs. You will have undefined behavior in 2
situations:
- use of the time facet in different threads
- creation of 2 locale instances from names in 2 threads at the same time

I will take a closer look to your code sample but as you can see there are
already known issues. The only problem is that I do not have a multicore or
hyperthreaded processor, I hope I will be able to see something on my
simple laptop. You should be able to play with a fixed version in about a
week (it should be in branch STLport.localization).

Bests


----------------------------------------------------------------------

Comment By: WorkerBee (workerbee)
Date: 2007-01-02 13:22

Message:
Logged In: YES 
user_id=1679913
Originator: YES

1. Sorry, but there is no mix of STLport versions.

It is only in the dsp-File because of the way Visual Studio organizes its
"configurations".
The Debug 5_1_0 is a copy of the original Debug configuration, and the
corresponding values have been changed afterwards.

2. I do know that

   while (running)

has no guards.

It's just there to end the threads in a defined way, I don't care when
"running" is read from memory, sooner or later all threads will get the
right value.
Of course, only if they have not crashed in the mean time, which is ALWAYS
the case on our multiprocessor systems.


So, what about the original multiprocessor issue ?

Could you help me, please ?


----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-02 09:49

Message:
Logged In: YES 
user_id=615813
Originator: NO

You mix two versions of STLport at least in debug:


...
!ELSEIF  "$(CFG)" == "localetest - Win32 Debug"
...
# ADD BASE ...
# ADD CPP ...  /I "../STLport-4.6.2/stlport" ...
#

!ELSEIF  "$(CFG)" == "localetest - Win32 Debug 5_1_0"

...
# ADD BASE CPP ... /I "../STLport-4.6.2/stlport" ...
# ADD CPP ... /I "../STLport-5.1.0/stlport" ...

...
# ADD BASE LINK32 ... /libpath:"../STLport-4.6.2/lib"
# ADD LINK32 ... /libpath:"../STLport-5.1.0/lib"
...

BTW, code has mistake too:

    while (running) {

don't has any guards. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1624993&group_id=146814

Bugs item #1624993, was opened at 2006-12-30 18:38
Message generated for change (Comment added) made by workerbee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1624993&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General code
Group: None
>Status: Open
Resolution: Invalid
Priority: 4
Private: No
Submitted By: WorkerBee (workerbee)
Assigned to: Francois Dumont (dums)
Summary: crash in locale code on multiprocessor system

Initial Comment:

* Platform:     Windows XP Professional, Windows 2003 Server
* Hardware:     Centrino Dual Core, Pentium D Dual Core
* Compiler:     Visual C++ 6.0 Service Pack 6
* STLPort:      Version 5.1.0 final version


We have experienced randomly crashes on our production system after switching
from STLport 4.6.2 to 5.1.0.

After some investigation it boils down to being a problem in the locale code
if used in more than one thread on multiprocessor/dual core systems.

Just creating and destroying some locale objects will crash the program on
multiprocessor/dual core systems after a few seconds only if more than one
thread is running.

I have verified the problem with the vanilla STL from Microsofts VC6 which of
course also crashes because it's known to be buggy.

Running the same program under STLport 4.6.2 shows no problems at all, it runs
without any crashes on these systems.

A have provided a simple test case to reproduce the problem.

Could someone please verify that this is a bug ?

Thanks,

Guenter




----------------------------------------------------------------------

>Comment By: WorkerBee (workerbee)
Date: 2007-01-30 19:13

Message:
Logged In: YES 
user_id=1679913
Originator: YES

After checking out the latest sources/trunk
I still am not happy with the fix:

  LeaveCriticalSection(&__criticalSection);
  return __FindFlag != 0 ? 0 : -1;

On really fast multiprocessor systems, this will not
work either:

You now correctly leave the critical section, but ...

Another thread might call __GetLCID, Entering the critical section
and setting

    __FindFlag = 0;

and oops, the first thread returns

__FindFlag != 0 ? 0 : -1;

-1 instead of 0, so the calling function will fail.

Shit happens. Do you agree?



----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-01-26 22:12

Message:
Logged In: YES 
user_id=1096600
Originator: NO

I agree I have been a little distracted on this point. Thanks for having
report it before 5.1.1 release.

About _Locale_init, you have the source so I am sure you know where it is
called. It is associated to Standard iostreams initialization (cout, cin,
...). It is compiler/platform dependent but you can consider that it is
called at library load time, even before you enter main, so at a
necessarily thread safe moment.

----------------------------------------------------------------------

Comment By: WorkerBee (workerbee)
Date: 2007-01-26 08:42

Message:
Logged In: YES 
user_id=1679913
Originator: YES

Well, maybe it is working, but ...
looking at the sources, I found (diff with previous revision)

Line 1747 
1747 	   if (__FindFlag == 0) return -1;
1748 	  	 
1749 	   *lcid = __FndLCID;
1750 	  	 
1751 	   LeaveCriticalSection(&__criticalSection);
1752 	   return 0;

Line 1747 is interesting, you will never leave the
critical section, which causes a deadlock.

This should be fixed ASAP.

BTW: where does void _Locale_init() get called (in a thread safe way) ?




----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-01-12 21:44

Message:
Logged In: YES 
user_id=1096600
Originator: NO

Fix is now available in 5.1 branch, it will be part of 5.1.1. It would be
great if you could check that it is solving your problems.

----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-01-03 22:10

Message:
Logged In: YES 
user_id=1096600
Originator: NO

Hi

What I find the most surprising in this bug report is that you do not
already have this problem with 4.6. I am working on improvements of
localization support and doing so I discovered several multi-threading
issues in Win32 portage. You can check by yourself in
src\c_locale_win32\c_locale_win32.c, you will find several static variables
that are the source of the bugs. You will have undefined behavior in 2
situations:
- use of the time facet in different threads
- creation of 2 locale instances from names in 2 threads at the same time

I will take a closer look to your code sample but as you can see there are
already known issues. The only problem is that I do not have a multicore or
hyperthreaded processor, I hope I will be able to see something on my
simple laptop. You should be able to play with a fixed version in about a
week (it should be in branch STLport.localization).

Bests


----------------------------------------------------------------------

Comment By: WorkerBee (workerbee)
Date: 2007-01-02 13:22

Message:
Logged In: YES 
user_id=1679913
Originator: YES

1. Sorry, but there is no mix of STLport versions.

It is only in the dsp-File because of the way Visual Studio organizes its
"configurations".
The Debug 5_1_0 is a copy of the original Debug configuration, and the
corresponding values have been changed afterwards.

2. I do know that

   while (running)

has no guards.

It's just there to end the threads in a defined way, I don't care when
"running" is read from memory, sooner or later all threads will get the
right value.
Of course, only if they have not crashed in the mean time, which is ALWAYS
the case on our multiprocessor systems.


So, what about the original multiprocessor issue ?

Could you help me, please ?


----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-02 09:49

Message:
Logged In: YES 
user_id=615813
Originator: NO

You mix two versions of STLport at least in debug:


...
!ELSEIF  "$(CFG)" == "localetest - Win32 Debug"
...
# ADD BASE ...
# ADD CPP ...  /I "../STLport-4.6.2/stlport" ...
#

!ELSEIF  "$(CFG)" == "localetest - Win32 Debug 5_1_0"

...
# ADD BASE CPP ... /I "../STLport-4.6.2/stlport" ...
# ADD CPP ... /I "../STLport-5.1.0/stlport" ...

...
# ADD BASE LINK32 ... /libpath:"../STLport-4.6.2/lib"
# ADD LINK32 ... /libpath:"../STLport-5.1.0/lib"
...

BTW, code has mistake too:

    while (running) {

don't has any guards. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1624993&group_id=146814

Bugs item #1646754, was opened at 2007-01-29 06:23
Message generated for change (Comment added) made by complement
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1646754&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General code
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Jin Qing (jinq0123)
>Assigned to: Petr Ovtchenkov (complement)
Summary: ostringstream::seekp(0, ios::beg) wrong

Initial Comment:

ostringstream::seekp(0, ios::beg) can not seek to the begin. 
ostringstream::seekp(0) is correct.

Following codes assert fail:
(VC6, stlport-5.1.0)

#include <sstream>
#include <iostream>
#include <string>
#include <cassert>

using namespace std;

int main()
{
    ostringstream oss;

    oss << "012345";
    // oss.seekp(0);           // RIGHT
    oss.seekp(0, ios::beg);    // WRONG
    oss << "X";
    assert("X12345" == oss.str());
    
    return 0;
}



----------------------------------------------------------------------

>Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-29 11:33

Message:
Logged In: YES 
user_id=615813
Originator: NO

As oss.seekp(0) as oss.seekp(0, ios::beg ) are correct, see standard.

Both pass through test, that I just added to trunk. If tests fail in you
case, resubmit bug. (Note: I check this in trunk).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1646754&group_id=146814

Bugs item #1645657, was opened at 2007-01-26 14:51
Message generated for change (Comment added) made by slobasso
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1645657&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General code
Group: None
>Status: Deleted
Resolution: None
Priority: 5
Private: No
Submitted By: Steve LoBasso (slobasso)
Assigned to: Nobody/Anonymous (nobody)
Summary: deque fails to meet 23.2.1.3.4-5 causing invalid iterators

Initial Comment:
deque fails to meet 23.2.1.3.4-5 causing invalid iterators and extra assignments

I recently found that deque iterators were being invalidated under some
circumstances when they shouldn't be.

After tracing the bug, I found it to be a bug introduced in the original SGI source. I've reported the problem to the libstdc++ people and they are fixing it.

See the following thread:
http://gcc.gnu.org/ml/libstdc++/2007-01/msg00098.html

In STLPort's case erase(begin()) on a deque with 2 elements will shuffle elements in the wrong direction and invalidate an iterator to the second element.

There are other circumstances as well.

It looks like STLPort has mostly fixed the bug, but it seems to be present in a few specializations to erase():

--- /tmp/STLport-5.1.0/stlport/stl/_deque.c        2006-05-23 13:01:06.000000000 -0700
+++ _deque.c    2007-01-26 14:37:11.250998000 -0800
@@ -192,21 +192,21 @@
   else
     _M_insert_range_aux(__pos, __first, __last, __n, _Movable());
 }
 
 #endif /* _STLP_MEMBER_TEMPLATES */
 
 template <class _Tp, class _Alloc >
 __iterator__ deque<_Tp,_Alloc>::_M_erase(iterator __pos,
                                          const __true_type& /*_Movable*/) {
   difference_type __index = __pos - this->_M_start;
-  if (size_type(__index) < this->size() >> 1) {
+  if (size_type(__index) <= this->size() >> 1) {
     //We move the start of the deque one position to the right
     //starting from the rightmost element to move.
     iterator __src = __pos, __dst = __pos;
     _STLP_STD::_Destroy(&(*__dst));
     if (__src != this->_M_start) {
       for (--__src; __dst != this->_M_start; --__src, --__dst) {
         _STLP_STD::_Move_Construct(&(*__dst), *__src);
         _STLP_STD::_Destroy_Moved(&(*__src));
       }
     }
@@ -229,21 +229,21 @@
   }
   return this->_M_start + __index;
 }
 
 template <class _Tp, class _Alloc >
 __iterator__ deque<_Tp,_Alloc>::_M_erase(iterator __pos,
                                          const __false_type& /*_Movable*/) {
   iterator __next = __pos;
   ++__next;
   difference_type __index = __pos - this->_M_start;
-  if (size_type(__index) < this->size() >> 1) {
+  if (size_type(__index) <= this->size() >> 1) {
     copy_backward(this->_M_start, __pos, __next);
     pop_front();
   }
   else {
     copy(__next, this->_M_finish, __pos);
     pop_back();
   }
   return this->_M_start + __index;
 }
 


----------------------------------------------------------------------

>Comment By: Steve LoBasso (slobasso)
Date: 2007-01-26 21:53

Message:
Logged In: YES 
user_id=140805
Originator: YES

I'm sorry, This is not a bug. I was incorrect.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1645657&group_id=146814

Bugs item #1645657, was opened at 2007-01-26 23:51
Message generated for change (Comment added) made by dums
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1645657&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General code
Group: None
>Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Steve LoBasso (slobasso)
>Assigned to: Francois Dumont (dums)
Summary: deque fails to meet 23.2.1.3.4-5 causing invalid iterators

Initial Comment:
deque fails to meet 23.2.1.3.4-5 causing invalid iterators and extra assignments

I recently found that deque iterators were being invalidated under some
circumstances when they shouldn't be.

After tracing the bug, I found it to be a bug introduced in the original SGI source. I've reported the problem to the libstdc++ people and they are fixing it.

See the following thread:
http://gcc.gnu.org/ml/libstdc++/2007-01/msg00098.html

In STLPort's case erase(begin()) on a deque with 2 elements will shuffle elements in the wrong direction and invalidate an iterator to the second element.

There are other circumstances as well.

It looks like STLPort has mostly fixed the bug, but it seems to be present in a few specializations to erase():

--- /tmp/STLport-5.1.0/stlport/stl/_deque.c        2006-05-23 13:01:06.000000000 -0700
+++ _deque.c    2007-01-26 14:37:11.250998000 -0800
@@ -192,21 +192,21 @@
   else
     _M_insert_range_aux(__pos, __first, __last, __n, _Movable());
 }
 
 #endif /* _STLP_MEMBER_TEMPLATES */
 
 template <class _Tp, class _Alloc >
 __iterator__ deque<_Tp,_Alloc>::_M_erase(iterator __pos,
                                          const __true_type& /*_Movable*/) {
   difference_type __index = __pos - this->_M_start;
-  if (size_type(__index) < this->size() >> 1) {
+  if (size_type(__index) <= this->size() >> 1) {
     //We move the start of the deque one position to the right
     //starting from the rightmost element to move.
     iterator __src = __pos, __dst = __pos;
     _STLP_STD::_Destroy(&(*__dst));
     if (__src != this->_M_start) {
       for (--__src; __dst != this->_M_start; --__src, --__dst) {
         _STLP_STD::_Move_Construct(&(*__dst), *__src);
         _STLP_STD::_Destroy_Moved(&(*__src));
       }
     }
@@ -229,21 +229,21 @@
   }
   return this->_M_start + __index;
 }
 
 template <class _Tp, class _Alloc >
 __iterator__ deque<_Tp,_Alloc>::_M_erase(iterator __pos,
                                          const __false_type& /*_Movable*/) {
   iterator __next = __pos;
   ++__next;
   difference_type __index = __pos - this->_M_start;
-  if (size_type(__index) < this->size() >> 1) {
+  if (size_type(__index) <= this->size() >> 1) {
     copy_backward(this->_M_start, __pos, __next);
     pop_front();
   }
   else {
     copy(__next, this->_M_finish, __pos);
     pop_back();
   }
   return this->_M_start + __index;
 }
 


----------------------------------------------------------------------

>Comment By: Francois Dumont (dums)
Date: 2007-01-28 08:34

Message:
Logged In: YES 
user_id=1096600
Originator: NO

I haven't check yet that we had this bug in the deque implementation but
what is sure is that iterator invalidation policy in the STL safe mode is
bugged. I will take care of fixing it in STLport 5.1 branch.

Thanks for the report.

----------------------------------------------------------------------

Comment By: Steve LoBasso (slobasso)
Date: 2007-01-27 06:53

Message:
Logged In: YES 
user_id=140805
Originator: YES

I'm sorry, This is not a bug. I was incorrect.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1645657&group_id=146814

Bugs item #1645657, was opened at 2007-01-26 23:51
Message generated for change (Comment added) made by dums
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1645657&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General code
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Steve LoBasso (slobasso)
Assigned to: Francois Dumont (dums)
Summary: deque fails to meet 23.2.1.3.4-5 causing invalid iterators

Initial Comment:
deque fails to meet 23.2.1.3.4-5 causing invalid iterators and extra assignments

I recently found that deque iterators were being invalidated under some
circumstances when they shouldn't be.

After tracing the bug, I found it to be a bug introduced in the original SGI source. I've reported the problem to the libstdc++ people and they are fixing it.

See the following thread:
http://gcc.gnu.org/ml/libstdc++/2007-01/msg00098.html

In STLPort's case erase(begin()) on a deque with 2 elements will shuffle elements in the wrong direction and invalidate an iterator to the second element.

There are other circumstances as well.

It looks like STLPort has mostly fixed the bug, but it seems to be present in a few specializations to erase():

--- /tmp/STLport-5.1.0/stlport/stl/_deque.c        2006-05-23 13:01:06.000000000 -0700
+++ _deque.c    2007-01-26 14:37:11.250998000 -0800
@@ -192,21 +192,21 @@
   else
     _M_insert_range_aux(__pos, __first, __last, __n, _Movable());
 }
 
 #endif /* _STLP_MEMBER_TEMPLATES */
 
 template <class _Tp, class _Alloc >
 __iterator__ deque<_Tp,_Alloc>::_M_erase(iterator __pos,
                                          const __true_type& /*_Movable*/) {
   difference_type __index = __pos - this->_M_start;
-  if (size_type(__index) < this->size() >> 1) {
+  if (size_type(__index) <= this->size() >> 1) {
     //We move the start of the deque one position to the right
     //starting from the rightmost element to move.
     iterator __src = __pos, __dst = __pos;
     _STLP_STD::_Destroy(&(*__dst));
     if (__src != this->_M_start) {
       for (--__src; __dst != this->_M_start; --__src, --__dst) {
         _STLP_STD::_Move_Construct(&(*__dst), *__src);
         _STLP_STD::_Destroy_Moved(&(*__src));
       }
     }
@@ -229,21 +229,21 @@
   }
   return this->_M_start + __index;
 }
 
 template <class _Tp, class _Alloc >
 __iterator__ deque<_Tp,_Alloc>::_M_erase(iterator __pos,
                                          const __false_type& /*_Movable*/) {
   iterator __next = __pos;
   ++__next;
   difference_type __index = __pos - this->_M_start;
-  if (size_type(__index) < this->size() >> 1) {
+  if (size_type(__index) <= this->size() >> 1) {
     copy_backward(this->_M_start, __pos, __next);
     pop_front();
   }
   else {
     copy(__next, this->_M_finish, __pos);
     pop_back();
   }
   return this->_M_start + __index;
 }
 


----------------------------------------------------------------------

>Comment By: Francois Dumont (dums)
Date: 2007-01-28 21:19

Message:
Logged In: YES 
user_id=1096600
Originator: NO

STL safe mode behavior has been fixed in 5.1 branch and merged to trunk.

Thanks for this (indirect) bug report.

----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-01-28 08:34

Message:
Logged In: YES 
user_id=1096600
Originator: NO

I haven't check yet that we had this bug in the deque implementation but
what is sure is that iterator invalidation policy in the STL safe mode is
bugged. I will take care of fixing it in STLport 5.1 branch.

Thanks for the report.

----------------------------------------------------------------------

Comment By: Steve LoBasso (slobasso)
Date: 2007-01-27 06:53

Message:
Logged In: YES 
user_id=140805
Originator: YES

I'm sorry, This is not a bug. I was incorrect.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1645657&group_id=146814

Bugs item #1645657, was opened at 2007-01-26 14:51
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1645657&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General code
Group: None
Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Steve LoBasso (slobasso)
Assigned to: Francois Dumont (dums)
Summary: deque fails to meet 23.2.1.3.4-5 causing invalid iterators

Initial Comment:
deque fails to meet 23.2.1.3.4-5 causing invalid iterators and extra assignments

I recently found that deque iterators were being invalidated under some
circumstances when they shouldn't be.

After tracing the bug, I found it to be a bug introduced in the original SGI source. I've reported the problem to the libstdc++ people and they are fixing it.

See the following thread:
http://gcc.gnu.org/ml/libstdc++/2007-01/msg00098.html

In STLPort's case erase(begin()) on a deque with 2 elements will shuffle elements in the wrong direction and invalidate an iterator to the second element.

There are other circumstances as well.

It looks like STLPort has mostly fixed the bug, but it seems to be present in a few specializations to erase():

--- /tmp/STLport-5.1.0/stlport/stl/_deque.c        2006-05-23 13:01:06.000000000 -0700
+++ _deque.c    2007-01-26 14:37:11.250998000 -0800
@@ -192,21 +192,21 @@
   else
     _M_insert_range_aux(__pos, __first, __last, __n, _Movable());
 }
 
 #endif /* _STLP_MEMBER_TEMPLATES */
 
 template <class _Tp, class _Alloc >
 __iterator__ deque<_Tp,_Alloc>::_M_erase(iterator __pos,
                                          const __true_type& /*_Movable*/) {
   difference_type __index = __pos - this->_M_start;
-  if (size_type(__index) < this->size() >> 1) {
+  if (size_type(__index) <= this->size() >> 1) {
     //We move the start of the deque one position to the right
     //starting from the rightmost element to move.
     iterator __src = __pos, __dst = __pos;
     _STLP_STD::_Destroy(&(*__dst));
     if (__src != this->_M_start) {
       for (--__src; __dst != this->_M_start; --__src, --__dst) {
         _STLP_STD::_Move_Construct(&(*__dst), *__src);
         _STLP_STD::_Destroy_Moved(&(*__src));
       }
     }
@@ -229,21 +229,21 @@
   }
   return this->_M_start + __index;
 }
 
 template <class _Tp, class _Alloc >
 __iterator__ deque<_Tp,_Alloc>::_M_erase(iterator __pos,
                                          const __false_type& /*_Movable*/) {
   iterator __next = __pos;
   ++__next;
   difference_type __index = __pos - this->_M_start;
-  if (size_type(__index) < this->size() >> 1) {
+  if (size_type(__index) <= this->size() >> 1) {
     copy_backward(this->_M_start, __pos, __next);
     pop_front();
   }
   else {
     copy(__next, this->_M_finish, __pos);
     pop_back();
   }
   return this->_M_start + __index;
 }
 


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-01-28 12:52

Message:
Logged In: NO 

Glad I could (unintentionally) help ;-)
I just wish the SGI sources could be fixed, because people still copy this
bad example regularly.

----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-01-28 12:19

Message:
Logged In: YES 
user_id=1096600
Originator: NO

STL safe mode behavior has been fixed in 5.1 branch and merged to trunk.

Thanks for this (indirect) bug report.

----------------------------------------------------------------------

Comment By: Francois Dumont (dums)
Date: 2007-01-27 23:34

Message:
Logged In: YES 
user_id=1096600
Originator: NO

I haven't check yet that we had this bug in the deque implementation but
what is sure is that iterator invalidation policy in the STL safe mode is
bugged. I will take care of fixing it in STLport 5.1 branch.

Thanks for the report.

----------------------------------------------------------------------

Comment By: Steve LoBasso (slobasso)
Date: 2007-01-26 21:53

Message:
Logged In: YES 
user_id=140805
Originator: YES

I'm sorry, This is not a bug. I was incorrect.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1645657&group_id=146814

Bugs item #1643639, was opened at 2007-01-24 18:48
Message generated for change (Comment added) made by complement
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1643639&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 2
Private: No
Submitted By: Petr Ovtchenkov (complement)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug list tracking

Initial Comment:
test

----------------------------------------------------------------------

>Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-24 19:09

Message:
Logged In: YES 
user_id=615813
Originator: YES

test more

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1643639&group_id=146814

Bugs item #1643639, was opened at 2007-01-24 18:48
Message generated for change (Comment added) made by complement
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1643639&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 2
Private: No
Submitted By: Petr Ovtchenkov (complement)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug list tracking

Initial Comment:
test

----------------------------------------------------------------------

>Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-24 19:26

Message:
Logged In: YES 
user_id=615813
Originator: YES

test 3

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-24 19:09

Message:
Logged In: YES 
user_id=615813
Originator: YES

test more

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1643639&group_id=146814

Bugs item #1643639, was opened at 2007-01-24 18:48
Message generated for change (Comment added) made by complement
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1643639&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 2
Private: No
Submitted By: Petr Ovtchenkov (complement)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug list tracking

Initial Comment:
test

----------------------------------------------------------------------

>Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-24 20:14

Message:
Logged In: YES 
user_id=615813
Originator: YES

test 4

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-24 19:26

Message:
Logged In: YES 
user_id=615813
Originator: YES

test 3

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-24 19:09

Message:
Logged In: YES 
user_id=615813
Originator: YES

test more

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1643639&group_id=146814

Bugs item #1643639, was opened at 2007-01-24 18:48
Message generated for change (Comment added) made by complement
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1643639&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 2
Private: No
Submitted By: Petr Ovtchenkov (complement)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug list tracking

Initial Comment:
test

----------------------------------------------------------------------

>Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-24 20:41

Message:
Logged In: YES 
user_id=615813
Originator: YES

test 5

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-24 20:14

Message:
Logged In: YES 
user_id=615813
Originator: YES

test 4

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-24 19:26

Message:
Logged In: YES 
user_id=615813
Originator: YES

test 3

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-24 19:09

Message:
Logged In: YES 
user_id=615813
Originator: YES

test more

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1643639&group_id=146814

Bugs item #1643686, was opened at 2007-01-24 19:44
Message generated for change (Comment added) made by complement
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1643686&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Deleted
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Aleksey Sanin (lsh123)
>Assigned to: Petr Ovtchenkov (complement)
Summary: crash in _Rb_global::_Rebalance_for_erase

Initial Comment:
The code erases elements one by one from *one* side of a set. After about 200 erases the crash occurs in the Rb_global<bool>::_Rebalance_for_erase () at stlport/stl/_tree.c:217.

The values for the variables around:

(gdb) print __w
$1 = (stlp_priv::_Rb_tree_node_base *) 0x0
(gdb) print __x
$2 = (stlp_priv::_Rb_tree_node_base *) 0x0
(gdb) print __x_parent
$3 = (stlp_priv::_Rb_tree_node_base *) 0x2dcc0
(gdb) print *__x_parent
$4 = {_M_color = true, _M_parent = 0x2de48, _M_left = 0x0, _M_right = 0x0}
(gdb) print __root
$5 = (stlp_priv::_Rb_tree_node_base *&) @0x2d4e4: 0x64328
*__x_parent->_M_parent->_M_parent->_M_parent->_M_parent->_M_parent->_M_parent->_M_parent
$6 = {_M_color = true, _M_parent = 0x2d4e0, _M_left = 0x63528, _M_right = 0x65f38}

It seems that both _M_left and _M_right for __x_parent are  NULL and I am not sure that this is a valid situation. However, the __x_parent itself is valid and I can go up all the way to the root.

Another note is that the crash occurs on Solaris SPARC 5.10 + gcc 3.4.6 in the release (-O2) mode only. It might be that this is a gcc bug. 

----------------------------------------------------------------------

>Comment By: Petr Ovtchenkov (complement)
Date: 2007-01-24 20:20

Message:
Logged In: YES 
user_id=615813
Originator: NO

http://stlport.sourceforge.net/BugReport.shtml

...
Ensure that this is a really bug (standard violation, incorrect behaviour
with correct usage).
Ensure that bug is in STLport, not in your code (you can use _STLP_DEBUG
for that, see stlport/stl_user_config.h).
...
Write short test that demonstrate this bug.
...
DON'T FORGET TO DESCRIBE:
 - OPERATIONAL ENVIRONMENT
 - COMPILER VERSION
 - STLPORT VERSION
 - RESULT OF UNIT TESTS

Keep in mind, that bug MUST be reproduced by other people, so give enough
information (but compactly, give only essential information), please. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=1643686&group_id=146814