|
From: <Voj...@se...> - 2008-01-23 16:08:01
|
Hello,
if I try to run memcheck on the following sample program I see only one-line stack trace for an error in thread created with pthread_create. The error in the main thread is shown well. Did I miss anything or is it a bug?
---------------------------------------------------------------------------------------------------------
the program:
#include <unistd.h> /* Symbolic Constants */
#include <sys/types.h> /* Primitive System Data Types */
#include <errno.h> /* Errors */
#include <stdio.h> /* Input/Output */
#include <stdlib.h> /* General Utilities */
#include <pthread.h> /* POSIX Threads */
//memory leak
void do_leak()
{
int* ptr = new int[10];
}
//mismatched new[]/delete
void do_mismatch()
{
int* ptr = new int[10];
delete ptr;
}
//run in the new thread
void* print_message_function ( void *ptr )
{
printf("new thread says Hello! \n");
//do_leak();
do_mismatch();
pthread_exit(0);
return NULL;
}
int main()
{
pthread_t thread1;
pthread_create (&thread1, NULL, &print_message_function, NULL);
do_leak();
//do_mismatch();
pthread_join(thread1, NULL);
exit(0);
}
---------------------------------------------------------------------------------------------------------
the output after running: valgrind --leak-check=full ./a.out
==21295== Memcheck, a memory error detector.
==21295== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==21295== Using LibVEX rev 1804, a library for dynamic binary translation.
==21295== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==21295== Using valgrind-3.3.0, a dynamic binary instrumentation framework.
==21295== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==21295== For more details, rerun with: -v
==21295==
==21295== My PID = 21295, parent PID = 20915. Prog and args are:
==21295== ./a.out
==21295==
==21295== Thread 2:
==21295== Mismatched free() / delete / delete []
==21295== at 0x4023779: operator delete(void*) (vg_replace_malloc.c:342)
==21295== Address 0x4a81138 is 0 bytes inside a block of size 40 alloc'd
==21295== at 0x4023079: operator new[](unsigned) (vg_replace_malloc.c:268)
==21295==
==21295== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 3 from 1)
==21295== malloc/free: in use at exit: 68 bytes in 2 blocks.
==21295== malloc/free: 4 allocs, 2 frees, 244 bytes allocated.
==21295== For counts of detected errors, rerun with: -v
==21295== searching for pointers to 2 not-freed blocks.
==21295== checked 134,892 bytes.
==21295==
==21295== Thread 1:
==21295==
==21295== 40 bytes in 1 blocks are definitely lost in loss record 2 of 2
==21295== at 0x4023079: operator new[](unsigned) (vg_replace_malloc.c:268)
==21295== by 0x804866B: do_leak() (thread-ex.cpp:11)
==21295== by 0x80486E9: main (thread-ex.cpp:38)
==21295==
==21295== LEAK SUMMARY:
==21295== definitely lost: 40 bytes in 1 blocks.
==21295== possibly lost: 0 bytes in 0 blocks.
==21295== still reachable: 28 bytes in 1 blocks.
==21295== suppressed: 0 bytes in 0 blocks.
==21295== Reachable blocks (those to which a pointer was found) are not shown.
==21295== To see them, rerun with: --leak-check=full --show-reachable=yes
---------------------------------------------------------------------------------------------------------
Vojtech
|
|
From: Julian S. <js...@ac...> - 2008-01-23 16:19:43
|
Hmm, that's strange. What gcc version are you using and what
flags did you compile this with?
J
On Wednesday 23 January 2008 17:07, Vojtech Fried wrote:
> Hello,
>
> if I try to run memcheck on the following sample program I see only
> one-line stack trace for an error in thread created with pthread_create.
> The error in the main thread is shown well. Did I miss anything or is it a
> bug?
>
> ---------------------------------------------------------------------------
>------------------------------ the program:
>
> #include <unistd.h> /* Symbolic Constants */
> #include <sys/types.h> /* Primitive System Data Types */
> #include <errno.h> /* Errors */
> #include <stdio.h> /* Input/Output */
> #include <stdlib.h> /* General Utilities */
> #include <pthread.h> /* POSIX Threads */
>
> //memory leak
> void do_leak()
> {
> int* ptr = new int[10];
> }
>
> //mismatched new[]/delete
> void do_mismatch()
> {
> int* ptr = new int[10];
> delete ptr;
> }
>
> //run in the new thread
> void* print_message_function ( void *ptr )
> {
> printf("new thread says Hello! \n");
>
> //do_leak();
> do_mismatch();
>
> pthread_exit(0);
> return NULL;
> }
>
> int main()
> {
> pthread_t thread1;
> pthread_create (&thread1, NULL, &print_message_function, NULL);
>
> do_leak();
> //do_mismatch();
>
> pthread_join(thread1, NULL);
> exit(0);
> }
>
> ---------------------------------------------------------------------------
>------------------------------ the output after running: valgrind
> --leak-check=full ./a.out
>
> ==21295== Memcheck, a memory error detector.
> ==21295== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==21295== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==21295== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==21295== Using valgrind-3.3.0, a dynamic binary instrumentation framework.
> ==21295== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==21295== For more details, rerun with: -v
> ==21295==
> ==21295== My PID = 21295, parent PID = 20915. Prog and args are:
> ==21295== ./a.out
> ==21295==
> ==21295== Thread 2:
> ==21295== Mismatched free() / delete / delete []
> ==21295== at 0x4023779: operator delete(void*) (vg_replace_malloc.c:342)
> ==21295== Address 0x4a81138 is 0 bytes inside a block of size 40 alloc'd
> ==21295== at 0x4023079: operator new[](unsigned)
> (vg_replace_malloc.c:268) ==21295==
> ==21295== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 3 from 1)
> ==21295== malloc/free: in use at exit: 68 bytes in 2 blocks.
> ==21295== malloc/free: 4 allocs, 2 frees, 244 bytes allocated.
> ==21295== For counts of detected errors, rerun with: -v
> ==21295== searching for pointers to 2 not-freed blocks.
> ==21295== checked 134,892 bytes.
> ==21295==
> ==21295== Thread 1:
> ==21295==
> ==21295== 40 bytes in 1 blocks are definitely lost in loss record 2 of 2
> ==21295== at 0x4023079: operator new[](unsigned)
> (vg_replace_malloc.c:268) ==21295== by 0x804866B: do_leak()
> (thread-ex.cpp:11)
> ==21295== by 0x80486E9: main (thread-ex.cpp:38)
> ==21295==
> ==21295== LEAK SUMMARY:
> ==21295== definitely lost: 40 bytes in 1 blocks.
> ==21295== possibly lost: 0 bytes in 0 blocks.
> ==21295== still reachable: 28 bytes in 1 blocks.
> ==21295== suppressed: 0 bytes in 0 blocks.
> ==21295== Reachable blocks (those to which a pointer was found) are not
> shown. ==21295== To see them, rerun with: --leak-check=full
> --show-reachable=yes
>
> ---------------------------------------------------------------------------
>------------------------------ Vojtech
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Vojtech F. <voj...@se...> - 2008-01-23 16:50:06
|
Julian Seward <jseward <at> acm.org> writes: > > > Hmm, that's strange. What gcc version are you using and what > flags did you compile this with? > > J Compiled simply with: g++ -g -lpthread thread-ex.cpp GCC version is 3.3.3 (We have to use this version in our project) Valgrind was compiled with this version too. Otherwise our system is OpenSuse 10.2 Vojtech |
|
From: Vojtech F. <voj...@se...> - 2008-01-25 10:49:59
|
I have probably found the cause of this problem. I have forgotten that our valgrind was patched to work better with wine (http://wiki.winehq.org/Wine_and_Valgrind). After building the original (not patched) source valgrind works as expected. |
|
From: Jim C. <jim...@gm...> - 2008-02-10 19:45:16
|
Vojtech Fried wrote: > I have probably found the cause of this problem. I have forgotten that our > valgrind was patched to work better with wine > (http://wiki.winehq.org/Wine_and_Valgrind). After building the original (not > patched) source valgrind works as expected. > > Please elaborate on this "better with wine" if your patch is not too invasive, and GPLable, maybe you and the devs can work thru it, and give everybody the improvements youve attempted with your patch. |
|
From: Dan K. <da...@ke...> - 2008-02-10 19:48:34
|
On Feb 10, 2008 11:44 AM, Jim Cromie <jim...@gm...> wrote: > Vojtech Fried wrote: > > I have probably found the cause of this problem. I have forgotten that our > > valgrind was patched to work better with wine > > (http://wiki.winehq.org/Wine_and_Valgrind). After building the original (not > > patched) source valgrind works as expected. > > Please elaborate on this "better with wine" Visit that web page, it explains. > if your patch is not too invasive, and GPLable, maybe you and the devs > can work thru it, and > give everybody the improvements youve attempted with your patch. It's not his patch. It's a bunch of valgrind changes to be compatible with Wine that have been rattling around for a couple years, most recently refreshed by John Reiser in December '07, I think John is planning to clean them up and try to get them integrated sometime this year. - Dan |
|
From: Tom H. <to...@co...> - 2008-02-10 21:50:03
|
In message <a71...@ma...>
"Dan Kegel" <da...@ke...> wrote:
> On Feb 10, 2008 11:44 AM, Jim Cromie <jim...@gm...> wrote:
>
> > Vojtech Fried wrote:
> >
> > > I have probably found the cause of this problem. I have forgotten that
> > > our valgrind was patched to work better with wine
> > > (http://wiki.winehq.org/Wine_and_Valgrind). After building the original
> > > (not patched) source valgrind works as expected.
> >
> > Please elaborate on this "better with wine"
>
> Visit that web page, it explains.
>
> > if your patch is not too invasive, and GPLable, maybe you and the devs
> > can work thru it, and give everybody the improvements youve attempted
> > with your patch.
>
> It's not his patch. It's a bunch of valgrind changes to be compatible with
> Wine that have been rattling around for a couple years, most recently
> refreshed by John Reiser in December '07, I think John is planning to
> clean them up and try to get them integrated sometime this year.
I think just about everything in the patch on winehq is in now. The
last bit was the stack stuff, and I committed that (or rather something
equivalent, and in fact better) last week.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dan K. <da...@ke...> - 2008-02-10 22:13:53
|
On Feb 10, 2008 1:49 PM, Tom Hughes <to...@co...> wrote: > I think just about everything in the patch on winehq is in now. The > last bit was the stack stuff, and I committed that (or rather something > equivalent, and in fact better) last week. Well, bust my buttons. Sure enough, valgrind from svn seems to work with Wine. I'm even getting good stack traces, which wasn't always happening before, so perhaps your stack stuff is in fact better. I guess I'll start testing it a bit more widely. Thanks! - Dan |
|
From: Julian S. <js...@ac...> - 2008-02-11 00:00:15
|
On Sunday 10 February 2008 23:13, Dan Kegel wrote: > On Feb 10, 2008 1:49 PM, Tom Hughes <to...@co...> wrote: > > I think just about everything in the patch on winehq is in now. The > > last bit was the stack stuff, and I committed that (or rather something > > equivalent, and in fact better) last week. > > Well, bust my buttons. Sure enough, valgrind from svn seems > to work with Wine. Hey, that's great news! J |