I compile example/http/server2 from boost (1.43) asio library using:
g++ -l boost_thread -l boost_system
/opt/boost/boost/doc/html/boost_asio/example/http/server2/*cpp
When I run it using valgrind drd (svn r11158) using:
valgrind --tool=drd ./a.out 127.0.0.1 31175 4 /tmp
The output is clean unti
On Mon, Jun 7, 2010 at 1:02 PM, Bart Van Assche wrote:
> On Mon, Jun 7, 2010 at 9:47 PM, Jorge Moraleda
> wrote:
>>
>> On Sat, Jun 5, 2010 at 5:47 AM, Bart Van Assche wrote:
>> > On Sat, Jun 5, 2010 at 2:52 AM, Jorge Moraleda
>> > wrote:
>> >&g
On Sat, Jun 5, 2010 at 5:47 AM, Bart Van Assche wrote:
> On Sat, Jun 5, 2010 at 2:52 AM, Jorge Moraleda
> wrote:
>>
>> I got a drd error in one of my programs, and searching on the web I
>> found the following boost bug report, including a test sample
>> reporting
I got a drd error in one of my programs, and searching on the web I
found the following boost bug report, including a test sample
reporting the same error found with drd.
https://svn.boost.org/trac/boost/ticket/3526 with a similar error.
There they seem to conclude that this is not a real problem,
On Wed, Jun 2, 2010 at 12:35 PM, Bart Van Assche wrote:
> On Wed, Jun 2, 2010 at 3:12 AM, Jorge Moraleda
> wrote:
>>
>> On Sun, May 30, 2010 at 12:56 AM, Jorge Moraleda
>> wrote:
>> > On Sat, May 29, 2010 at 10:56 PM, Bart Van Assche
>> > wrote:
&g
On Sun, May 30, 2010 at 12:56 AM, Jorge Moraleda
wrote:
> On Sat, May 29, 2010 at 10:56 PM, Bart Van Assche wrote:
>> On Sat, May 29, 2010 at 7:00 PM, Jorge Moraleda
>> wrote:
>>>
>>> I submitted a condition variable not initialized detected with
>>> v
On Sat, May 29, 2010 at 10:56 PM, Bart Van Assche wrote:
> On Sat, May 29, 2010 at 7:00 PM, Jorge Moraleda
> wrote:
>>
>> I submitted a condition variable not initialized detected with
>> valgrind drd to the boost mailing list, but they report that it is a
>> false
I submitted a condition variable not initialized detected with
valgrind drd to the boost mailing list, but they report that it is a
false alarm:
Date: Sat, 29 May 2010 09:29:23 +0400
From: Andrey Semashev
On 05/29/2010 02:06 AM, Jorge Moraleda wrote:
> When testing boost.log for race conditi
On Thu, May 27, 2010 at 3:42 AM, Bart Van Assche wrote:
> On Thu, May 27, 2010 at 4:29 AM, Jorge Moraleda
> wrote:
>>
>> Dear all,
>>
>> Am I doing something wrong, or is is there a race condition somewhere
>> in std::istringstream and/or std::getline?
&g
Dear all,
Am I doing something wrong, or is is there a race condition somewhere
in std::istringstream and/or std::getline?
(Bart, Konstantin, this ended up being the error that I've been trying
to track down for a while and that I thought --erroneously-- was
caused by std::locale)
This program:
>>>
>>> Why did you post this in reply to a message about std::locale::locale() ?
>>> As far as I can see the race reported on the std::string object and the race
>>> reported on std::locale::locale() are unrelated.
>>>
>>> Oops, my fault...
>> Indeed, a reproducer for a std::locale::locale() would
>> I have a program that makes massif crash reproducibly with a
>> segmentation fault. This occurs in the release version 3.5.0 as well
>> as in one compiled from source today from subversion:
>> valgrind-3.6.0.SVN. The program runs fine in massif 3.3.1 compiled
>> from source. This crash occurs re
Dear all,
I have a program that makes massif crash reproducibly with a
segmentation fault. This occurs in the release version 3.5.0 as well
as in one compiled from source today from subversion:
valgrind-3.6.0.SVN. The program runs fine in massif 3.3.1 compiled
from source. This crash occurs reprod
>> Hello Jorge,
>>
>> Unfortunately not all libraries have been designed with data-race
>> detection tools in mind. Several libraries contain code that triggers
>> benign data races. Examples are the I/O code in libstdc++ and in libc.
>>
>> You can either create a suppression pattern to suppress th
>
>
> > I found the following bug-report against gcc:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518
> > It seems that the problem is fixed in gcc 4.5. Until it is released, I
> > added code to my application to not clear empty strings, and it seems
> > to solve all the these problems. Thank
>
> #include
> #include
> #include
>
> void *threadEntry(void *threadid)
> {
> long tid;
> tid = (long)threadid;
> std::string myString;
> for (int i = 0; i<5; i++) {
> myString.clear();
> pthread_yield();
> }
> pthread_exit(NUL
On Tue, Apr 6, 2010 at 3:30 AM, Bart Van Assche wrote:
> On Tue, Apr 6, 2010 at 12:25 PM, Konstantin Serebryany
> wrote:
>>
>>
>> On Tue, Apr 6, 2010 at 2:17 PM, Bart Van Assche wrote:
>>>
>>> On Tue, Apr 6, 2010 at 7:53 AM, Jorge Moraleda
>>&
ad that it is
protected by a global mutex.
By the way, if in the program above I don't include iostream, then drd
reports almost a thousand errors from a hundred contexts!
Thank you very much!
Jorge Moraleda
FYI: I am running ubuntu linux 9.10. This is my system:
$ valgrind --version
valg
18 matches
Mail list logo