Hi
I have checked a TCP-server which i wrote with valgrind-3.4.0,
and encountered these errors:
==15611== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 17 from 1)
==15611==
==15611== 1 errors in context 1 of 2:
==15611== Syscall param socketcall.accept(addr) points to unaddressable byte(s)
On Wed, Jan 28, 2009 at 11:06 AM, jody jody@gmail.com wrote:
Hi
I have checked a TCP-server which i wrote with valgrind-3.4.0,
and encountered these errors:
==15611== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 17 from 1)
==15611==
==15611== 1 errors in context 1 of 2:
On Wed, 28 Jan 2009 11:06:37 +0100
jody jody@gmail.com wrote:
Hi
I have checked a TCP-server which i wrote with valgrind-3.4.0,
and encountered these errors:
==15611== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 17 from 1)
==15611==
==15611== 1 errors in context 1 of 2:
Thanks for the explanation - that fixed the issue!
Jody
On Wed, Jan 28, 2009 at 11:27 AM, Tom Hughes t...@compton.nu wrote:
jody wrote:
I simplified the server to the point where it only calls accept (see
below),
and the errors still prevail.
I compile it with
g++ -g -Wall dummysrv.cpp
Hi
I have a server which creates a new detached pthread every time it
accepts a new connection.
Inside such a thread an object is created which modifies a std:vector.
At the end of the program, long after the connection has terminated,
and very probably after the thread has finished, said object
I have a server which creates a new detached pthread every time it
accepts a new connection.
Hmm, detached threads are bad news, at least from a race detection
point of view. See
http://www.valgrind.org/docs/manual/hg-manual.html#hg-manual.effective-use
point 5 (Round up all finished
I agree to these comments, but would also recommend to not *only* use
helgrind but also the new DRD tool. DRD did an excellent job for my
project. The newest release now contains a stable release.
Just my 2cts...
Rainer
On Wed, Jan 28, 2009 at 6:44 PM, Julian Seward jsew...@acm.org wrote:
I
