[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

2006-10-31 Thread l_heldt at poczta dot onet dot pl
--- Comment #20 from l_heldt at poczta dot onet dot pl 2006-10-31 17:23 --- (In reply to comment #16) > (In reply to comment #15) > > I tried to prepare a simple testcase but without any success. It seems to be > > extremely hard to hit the moment when pointers are a

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

2006-10-31 Thread l_heldt at poczta dot onet dot pl
--- Comment #15 from l_heldt at poczta dot onet dot pl 2006-10-31 13:42 --- (In reply to comment #14) > (In reply to comment #13) > > We actually encountered this problem - this is not taken from code review > > only. > > Again, adding a mutex to that those

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

2006-10-31 Thread l_heldt at poczta dot onet dot pl
--- Comment #13 from l_heldt at poczta dot onet dot pl 2006-10-31 13:12 --- (In reply to comment #12) > About _M_detach_all specifically, it's called only by ~_Safe_sequence_base(), > thus only when the container itself is destructed. Therefore, I don't think it > ma

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

2006-10-31 Thread l_heldt at poczta dot onet dot pl
--- Comment #8 from l_heldt at poczta dot onet dot pl 2006-10-31 11:12 --- There is a similar problem in _M_detach_all() function. It iterates through list of iterators without obtaining lock. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29496

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

2006-10-19 Thread l_heldt at poczta dot onet dot pl
--- Comment #7 from l_heldt at poczta dot onet dot pl 2006-10-19 13:51 --- (In reply to comment #2) > Please attach a complete test case, not a sketch. > > -benjamin > This bug is a pure race-condition. There is no test case which would reveal it with a 100% certa

[Bug c++/29496] New: _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

2006-10-18 Thread l_heldt at poczta dot onet dot pl
at poczta dot onet dot pl GCC host triplet: Linux 2.6.9-42.ELsmp #1 SMP http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29496

[Bug c++/27836] Compiler generates bad assembler code for xaddl __asm__ function

2006-05-31 Thread l_heldt at poczta dot onet dot pl
--- Comment #3 from l_heldt at poczta dot onet dot pl 2006-05-31 11:43 --- Can you tell me how correct asm body should look like? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27836

[Bug c++/27836] Compiler generates bad assembler code for xaddl __asm__ function

2006-05-31 Thread l_heldt at poczta dot onet dot pl
--- Comment #1 from l_heldt at poczta dot onet dot pl 2006-05-31 11:14 --- Problem does not show up in g++-4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27836

[Bug c++/27836] New: Compiler generates bad assembler code for xaddl __asm__ function

2006-05-31 Thread l_heldt at poczta dot onet dot pl
ts random data. -- Summary: Compiler generates bad assembler code for xaddl __asm__ function Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc do

[Bug c++/27045] c++ is generating incorrect optimized code for xor operations on long long

2006-04-05 Thread l_heldt at poczta dot onet dot pl
--- Comment #3 from l_heldt at poczta dot onet dot pl 2006-04-05 15:18 --- After compilation: g++ test.cpp req.cpp -O0 program works fine. After compilation with: g++ test.cpp req.cpp -O2 it breaks with SIGABRT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27045

[Bug c++/27045] c++ is generating incorrect optimized code for xor operations on long long

2006-04-05 Thread l_heldt at poczta dot onet dot pl
--- Comment #2 from l_heldt at poczta dot onet dot pl 2006-04-05 15:17 --- Created an attachment (id=11213) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11213&action=view) Implementation of RequestId -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27045

[Bug c++/27045] c++ is generating incorrect optimized code for xor operations on long long

2006-04-05 Thread l_heldt at poczta dot onet dot pl
--- Comment #1 from l_heldt at poczta dot onet dot pl 2006-04-05 15:17 --- Created an attachment (id=11212) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11212&action=view) File containing hash specifications -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27045

[Bug c++/27045] New: c++ is generating incorrect optimized code for xor operations on long long

2006-04-05 Thread l_heldt at poczta dot onet dot pl
d at gcc dot gnu dot org ReportedBy: l_heldt at poczta dot onet dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27045

[Bug libstdc++/24469] Possible race condition in mt_allocator causing SIGSEGV

2005-11-15 Thread l_heldt at poczta dot onet dot pl
--- Comment #4 from l_heldt at poczta dot onet dot pl 2005-11-15 12:26 --- Unfortunately I cannot perform such test because it would require changing stdlibc++ on many machines. My solution to this problem is setting GLIBCXX_FORCE_NEW variable before starting application. -- http

[Bug libstdc++/24469] New: Possible race condition in mt_allocator causing SIGSEGV

2005-10-21 Thread l_heldt at poczta dot onet dot pl
Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: critical Priority: P1 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: l_heldt at poczta dot onet dot pl GCC host triplet: Linux 2.6.12 #4 S

[Bug libstdc++/19265] problem with _S_destroy_thread_key when using dynamic libraries

2005-01-17 Thread l_heldt at poczta dot onet dot pl
--- Additional Comments From l_heldt at poczta dot onet dot pl 2005-01-17 14:12 --- I cannot check proposed changes because of compilation problems. I have changed makefiles in libstdc++/src directory but I am getting errors while linking: /remote/beta4/lukasz/gcc2/gcc/g++ -shared

[Bug libstdc++/19265] problem with _S_destroy_thread_key when using dynamic libraries

2005-01-05 Thread l_heldt at poczta dot onet dot pl
--- Additional Comments From l_heldt at poczta dot onet dot pl 2005-01-05 15:54 --- I have used following scenario: 1. dlopen dynamic library 2. execute a method inside dynamic library which addes integer to vector 3. dlclose 4. try to exit cleanly Program crashes with SIGSEGV

[Bug libstdc++/19265] New: problem with _S_destroy_thread_key when using dynamic libraries

2005-01-05 Thread l_heldt at poczta dot onet dot pl
oduct: gcc Version: 3.4.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: l_heldt at poczta dot onet dot pl CC: gcc-bugs at gcc dot gn