|
From: Nuno L. <nun...@sa...> - 2006-12-22 16:25:14
|
Hi, I'm already using a valgrind 3.2.2 patch provided by Julian Seward himself (http://sourceforge.net/mailarchive/message.php?msg_id=37706183), but --gen-suppressions is still not working for some edge cases. For example: ==17024== Invalid read of size 8 ==17024== at 0x87839B8: (within /p2/var/php_gcov/PHP_HEAD/sapi/cli/php) ==17024== Address 0x6C380E8 is 96 bytes inside a block of size 102 alloc'd ==17024== at 0x401DD95: realloc (vg_replace_malloc.c:306) ==17024== by 0x57EE3E3: nlolgserv (in /p2/usr/lib/oracle/xe/app/oracle/produc/10.2.0/server/lib/libclntsh.so.10.1) ==17024== by 0x57EE787: nlolgobj (in /p2/usr/lib/oracle/xe/app/oracle/product10.2.0/server/lib/libclntsh.so.10.1) ==17024== by 0x56E49A1: nnfun2a (in /p2/usr/lib/oracle/xe/app/oracle/product/0.2.0/server/lib/libclntsh.so.10.1) ==17024== by 0x56E4613: nnfsn2a (in /p2/usr/lib/oracle/xe/app/oracle/product/0.2.0/server/lib/libclntsh.so.10.1) ==17024== by 0x57256C4: niqname (in /p2/usr/lib/oracle/xe/app/oracle/product/0.2.0/server/lib/libclntsh.so.10.1) ==17024== by 0x5650D14: kwfnran (in /p2/usr/lib/oracle/xe/app/oracle/product/0.2.0/server/lib/libclntsh.so.10.1) ==17024== by 0x5619E33: kwfcinit (in /p2/usr/lib/oracle/xe/app/oracle/product10.2.0/server/lib/libclntsh.so.10.1) ==17024== by 0x547D59A: kpuatch (in /p2/usr/lib/oracle/xe/app/oracle/product/0.2.0/server/lib/libclntsh.so.10.1) ==17024== by 0x5597990: OCIServerAttach (in /p2/usr/lib/oracle/xe/app/oracle/roduct/10.2.0/server/lib/libclntsh.so.10.1) ==17024== by 0x8252F3E: php_oci_do_connect_ex (oci8.c:1282) ==17024== by 0x825092A: php_oci_do_connect (oci8.c:1005) { <insert a suppression name here> Memcheck:Addr8 obj:/p2/var/php_gcov/PHP_HEAD/sapi/cli/php } The generated suppression should (in theory) suppress all invalid-read-size-8 errors from the php binary, so it is pretty useless (I want to fetch them afterall). I already tried a few combinations of suppressions, but I wasn't able to shut it up, like: { oracleXE6 Memcheck:Value8 obj:/p2/var/php_gcov/*/sapi/cli/php (with and without this line) fun:realloc fun:nlolgserv obj:/p2/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib/libclntsh.so.10.1 } Can you help me (again) sorting out this problem please? Thanks, Nuno |
|
From: Tom H. <to...@co...> - 2006-12-22 16:31:09
|
In message <002701c725e5$bee0f1e0$0100a8c0@pc07653>
"Nuno Lopes" <nun...@sa...> wrote:
> I'm already using a valgrind 3.2.2 patch provided by Julian Seward himself
> (http://sourceforge.net/mailarchive/message.php?msg_id=37706183),
> but --gen-suppressions is still not working for some edge cases.
>
> For example:
> ==17024== Invalid read of size 8
> ==17024== at 0x87839B8: (within /p2/var/php_gcov/PHP_HEAD/sapi/cli/php)
So this is where the read happened.
> ==17024== Address 0x6C380E8 is 96 bytes inside a block of size 102 alloc'd
> ==17024== at 0x401DD95: realloc (vg_replace_malloc.c:306)
> ==17024== by 0x57EE3E3: nlolgserv (in
> /p2/usr/lib/oracle/xe/app/oracle/produc/10.2.0/server/lib/libclntsh.so.10.1)
> ==17024== by 0x57EE787: nlolgobj (in
> /p2/usr/lib/oracle/xe/app/oracle/product10.2.0/server/lib/libclntsh.so.10.1)
> ==17024== by 0x56E49A1: nnfun2a (in
> /p2/usr/lib/oracle/xe/app/oracle/product/0.2.0/server/lib/libclntsh.so.10.1)
> ==17024== by 0x56E4613: nnfsn2a (in
> /p2/usr/lib/oracle/xe/app/oracle/product/0.2.0/server/lib/libclntsh.so.10.1)
> ==17024== by 0x57256C4: niqname (in
> /p2/usr/lib/oracle/xe/app/oracle/product/0.2.0/server/lib/libclntsh.so.10.1)
> ==17024== by 0x5650D14: kwfnran (in
> /p2/usr/lib/oracle/xe/app/oracle/product/0.2.0/server/lib/libclntsh.so.10.1)
> ==17024== by 0x5619E33: kwfcinit (in
> /p2/usr/lib/oracle/xe/app/oracle/product10.2.0/server/lib/libclntsh.so.10.1)
> ==17024== by 0x547D59A: kpuatch (in
> /p2/usr/lib/oracle/xe/app/oracle/product/0.2.0/server/lib/libclntsh.so.10.1)
> ==17024== by 0x5597990: OCIServerAttach (in
> /p2/usr/lib/oracle/xe/app/oracle/roduct/10.2.0/server/lib/libclntsh.so.10.1)
> ==17024== by 0x8252F3E: php_oci_do_connect_ex (oci8.c:1282)
> ==17024== by 0x825092A: php_oci_do_connect (oci8.c:1005)
and this is where the block you are reading was allocated (but you are
reading two bytes past the end of the block).
> {
> <insert a suppression name here>
> Memcheck:Addr8
> obj:/p2/var/php_gcov/PHP_HEAD/sapi/cli/php
> }
>
>
> The generated suppression should (in theory) suppress all
> invalid-read-size-8 errors from the php binary, so it is pretty useless (I
> want to fetch them afterall).
But there is no more information - probably there is too much
optimisation and/or too little debugging in the PHP library for
valgrind to be able to trace the stack back any further
> I already tried a few combinations of suppressions, but I wasn't able to
> shut it up, like:
> {
> oracleXE6
> Memcheck:Value8
> obj:/p2/var/php_gcov/*/sapi/cli/php (with and without this line)
> fun:realloc
> fun:nlolgserv
> obj:/p2/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib/libclntsh.so.10.1
> }
You're mixing up the two traces there. You can't suppress based on
where the block was allocated anyway, so you only have that one line
to go on which obviously isn't enough.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nuno L. <nun...@sa...> - 2006-12-27 17:30:29
|
>>> For example: >>> ==17024== Invalid read of size 8 >>> ==17024== at 0x87839B8: (within >>> /p2/var/php_gcov/PHP_HEAD/sapi/cli/php) >> >> So this is where the read happened. > > Uhm, I'm almost sure this problem isn't triggered in PHP code, but rather > in > the oracle lib. Do you know any way to dump the assembly of that address > to > help me tracking the problem (or some tool..)? so, here is quick update: in a fresh binary, valgrind reports: $ cat ext/oci8/tests/array_bind_002.mem ==22651== Invalid read of size 8 ==22651== at 0x87E12A8: (within /p2/var/php_gcov/PHP_5_2/sapi/cli/php) $ readelf -a sapi/cli/php | grep 087e12 9528: 087e1200 0 NOTYPE LOCAL DEFAULT 12 movdqa2 9529: 087e1250 0 NOTYPE LOCAL DEFAULT 12 movdqa3 9530: 087e12a0 0 NOTYPE LOCAL DEFAULT 12 movdqa4 9531: 087e12f0 0 NOTYPE LOCAL DEFAULT 12 movdqa5 So it seems the error is beeing caused by the movdqa4 function. Searching a little on the web makes me think that the oracle lib was compiled with the intel c++ compiler, which introduces those movdqa* functions. AFAIK, the oracle libs are linked dynamically, so I don't know how those symbols got in... Any suggestions? Nuno |
|
From: Nuno L. <nun...@sa...> - 2006-12-27 17:10:51
|
Thanks for your fast answer and sorry for my delay. >> I'm already using a valgrind 3.2.2 patch provided by Julian Seward >> himself >> (http://sourceforge.net/mailarchive/message.php?msg_id=37706183), >> but --gen-suppressions is still not working for some edge cases. >> >> For example: >> ==17024== Invalid read of size 8 >> ==17024== at 0x87839B8: (within >> /p2/var/php_gcov/PHP_HEAD/sapi/cli/php) > > So this is where the read happened. Uhm, I'm almost sure this problem isn't triggered in PHP code, but rather in the oracle lib. Do you know any way to dump the assembly of that address to help me tracking the problem (or some tool..)? >> { >> <insert a suppression name here> >> Memcheck:Addr8 >> obj:/p2/var/php_gcov/PHP_HEAD/sapi/cli/php >> } >> >> >> The generated suppression should (in theory) suppress all >> invalid-read-size-8 errors from the php binary, so it is pretty useless >> (I >> want to fetch them afterall). > > But there is no more information - probably there is too much > optimisation and/or too little debugging in the PHP library for > valgrind to be able to trace the stack back any further Well, PHP is compiled with -g and has no "dirty" optimizations.. Thanks, Nuno |
|
From: Nuno L. <nun...@sa...> - 2007-01-10 22:20:28
|
Hello again, >> For example: >> ==17024== Invalid read of size 8 >> ==17024== at 0x87839B8: (within >> /p2/var/php_gcov/PHP_HEAD/sapi/cli/php) > > So this is where the read happened. I have traced this error and it happens inside a function named movdqa4. The problem is that it hasn't any debug symbols associated and it is local. nm reports: 08807eb0 t movdqa4 08809620 t movdqa4 objdump -D: 08807eb0 <movdqa4>: 8807eb0: 83 e9 20 sub $0x20,%ecx 8807eb3: 66 0f 6f 5e 10 movdqa 0x10(%esi),%xmm3 8807eb8: 66 0f 6f 46 20 movdqa 0x20(%esi),%xmm0 <-- this is the line that cause the warning 8807ebd: 83 c6 20 add $0x20,%esi 8807ec0: 66 0f 73 d9 04 psrldq $0x4,%xmm1 (...) These movdqa* functions are introduced by the intel compiler through their libirc.a lib, so I have no control over them nor I have a way to add debug symbols to their objects files. So it seems that valgrind only uses the function names from the debug data, and doesn't use the symbol table. Would it be possible to use the symbol table? (I mean fallback to it when no debug symbols are found) Thanks in advance, Nuno Lopes |
|
From: Nicholas N. <nj...@cs...> - 2007-01-10 22:57:21
|
On Wed, 10 Jan 2007, Nuno Lopes wrote: > So it seems that valgrind only uses the function names from the debug data, > and doesn't use the symbol table. Would it be possible to use the symbol > table? (I mean fallback to it when no debug symbols are found) It already does this. That's why you get error messages like this if there is no debug info: ==29800== Use of uninitialised value of size 4 ==29800== at 0x80483B9: main (in /home/njn/grind/trunk5/a.out) Nick |
|
From: Nuno L. <nun...@sa...> - 2007-01-10 23:03:38
|
> On Wed, 10 Jan 2007, Nuno Lopes wrote: > >> So it seems that valgrind only uses the function names from the debug >> data, >> and doesn't use the symbol table. Would it be possible to use the symbol >> table? (I mean fallback to it when no debug symbols are found) > > It already does this. That's why you get error messages like this if > there is no debug info: > > ==29800== Use of uninitialised value of size 4 > ==29800== at 0x80483B9: main (in /home/njn/grind/trunk5/a.out) At least not valgrind 3.2.1 or at least not always. I get this: ==4643== Invalid read of size 8 ==4643== at 0x8807EB8: (within /p2/var/php_gcov/PHP_5_2/sapi/cli/php) ==4643== Address 0x637A0F8 is 96 bytes inside a block of size 102 alloc'd ==4643== at 0x401CD95: realloc (vg_replace_malloc.c:306) (...) Clearly it misses the function name. Nuno |
|
From: Julian S. <js...@ac...> - 2007-01-10 23:09:37
|
> objdump -D: > 08807eb0 <movdqa4>: > 8807eb0: 83 e9 20 sub $0x20,%ecx > 8807eb3: 66 0f 6f 5e 10 movdqa 0x10(%esi),%xmm3 > 8807eb8: 66 0f 6f 46 20 movdqa 0x20(%esi),%xmm0 <-- this > is the line that cause the warning > 8807ebd: 83 c6 20 add $0x20,%esi > 8807ec0: 66 0f 73 d9 04 psrldq $0x4,%xmm1 Your timing is good. I just chased this problem around two days ago. I believe it is the same as bug 139776. See http://bugs.kde.org/show_bug.cgi?id=139776 which also contains a suggested fix, near the end. Can you let me know whether this helps for you. One thing that would be very helpful if you could find out is, in which part of your program is the symbol _intel_fast_memcpy? That is, is it defined in the main executable, or in one of the shared objects for the Intel runtime support, or where? J |
|
From: Nuno L. <nun...@sa...> - 2007-01-10 23:25:00
|
>> objdump -D: >> 08807eb0 <movdqa4>: >> 8807eb0: 83 e9 20 sub $0x20,%ecx >> 8807eb3: 66 0f 6f 5e 10 movdqa 0x10(%esi),%xmm3 >> 8807eb8: 66 0f 6f 46 20 movdqa 0x20(%esi),%xmm0 <-- >> this >> is the line that cause the warning >> 8807ebd: 83 c6 20 add $0x20,%esi >> 8807ec0: 66 0f 73 d9 04 psrldq $0x4,%xmm1 > > Your timing is good. I just chased this problem around two days ago. > I believe it is the same as bug 139776. See great then :) > which also contains a suggested fix, near the end. Can you let me > know whether this helps for you. My problem is unrelated with _intel_fast_memcpy. I had _intel_fast_memcmp generating warnings, but that on was easy to suppress (Memcheck:Cond\n fun:_intel_fast_memcmp). My problem is that valgrind isn't fetching the function name (maybe because it isn't global, as it lookups the _intel_fast_memcmp symbol correctly). > One thing that would be very helpful if you could find out is, > in which part of your program is the symbol _intel_fast_memcpy? > That is, is it defined in the main executable, or in one of the > shared objects for the Intel runtime support, or where? It also comes from the libirc.a library, which is linked automatically when using certain optimizations. 'nm' reports the symbol as T (.text & global) You may also want the assembly (objdump -D): 088071bc <_intel_fast_memcpy.A>: 88071bc: 57 push %edi 88071bd: 56 push %esi 88071be: 8b 74 24 10 mov 0x10(%esp),%esi 88071c2: 8b 7c 24 0c mov 0xc(%esp),%edi 88071c6: 8b 4c 24 14 mov 0x14(%esp),%ecx 88071ca: f3 a4 repz movsb %ds:(%esi),%es:(%edi) 88071cc: 8b 44 24 0c mov 0xc(%esp),%eax 88071d0: 5e pop %esi 88071d1: 5f pop %edi 88071d2: c3 ret 88071d3: 90 nop 088071d4 <_intel_fast_memcpy.J>: 88071d4: ff 74 24 0c pushl 0xc(%esp) 88071d8: ff 74 24 0c pushl 0xc(%esp) 88071dc: ff 74 24 0c pushl 0xc(%esp) 88071e0: e8 5b 08 00 00 call 8807a40 <__intel_new_memcpy> 88071e5: 83 c4 0c add $0xc,%esp 88071e8: c3 ret 88071e9: 90 nop 088071ea <_intel_fast_memcpy.H>: 88071ea: ff 74 24 0c pushl 0xc(%esp) 88071ee: ff 74 24 0c pushl 0xc(%esp) 88071f2: ff 74 24 0c pushl 0xc(%esp) 88071f6: e8 a5 1f 00 00 call 88091a0 <__intel_new_memcpy_P3> 88071fb: 83 c4 0c add $0xc,%esp 88071fe: c3 ret 88071ff: 90 nop 08807200 <_intel_fast_memcpy>: 8807200: f7 05 e8 a7 c9 08 00 testl $0xfffffe00,0x8c9a7e8 8807207: fe ff ff 880720a: 0f 85 c4 ff ff ff jne 88071d4 <_intel_fast_memcpy.J> 8807210: f7 05 e8 a7 c9 08 80 testl $0xffffff80,0x8c9a7e8 8807217: ff ff ff 880721a: 0f 85 ca ff ff ff jne 88071ea <_intel_fast_memcpy.H> 8807220: f7 05 e8 a7 c9 08 ff testl $0xffffffff,0x8c9a7e8 8807227: ff ff ff 880722a: 0f 85 8c ff ff ff jne 88071bc <_intel_fast_memcpy.A> 8807230: e8 79 ff ff ff call 88071ae <__intel_cpu_indicator_init> 8807235: eb c9 jmp 8807200 <_intel_fast_memcpy> 8807237: c3 ret Nuno |
|
From: Julian S. <js...@ac...> - 2007-01-10 23:32:14
|
> > Your timing is good. I just chased this problem around two days ago. > > I believe it is the same as bug 139776. See > > great then :) > > > which also contains a suggested fix, near the end. Can you let me > > know whether this helps for you. > > My problem is unrelated with _intel_fast_memcpy. I had _intel_fast_memcmp > generating warnings, but that on was easy to suppress (Memcheck:Cond\n > fun:_intel_fast_memcmp). > My problem is that valgrind isn't fetching the function name (maybe because > it isn't global, as it lookups the _intel_fast_memcmp symbol correctly). I am not convinced the root cause is _intel_fast_memcmp. It might be, or there might be multiple problems here. Did you try the change I suggested? Do you have a way I can reproduce this for further investigation here? That would be the most helpful. J |
|
From: Nuno L. <nun...@sa...> - 2007-01-11 14:55:02
|
> I have now tried it, but the _intel_fast_memcmp warnings still appear. > reports without suppressions: > http://gcov.php.net/~nlopess/vg1.txt - test execution with valgrind 3.2.1 > http://gcov.php.net/~nlopess/vg2.txt - same, but with your patch > http://gcov.php.net/~nlopess/array_bind_004.mem - execution of the test > through our test suite > http://gcov.php.net/~nlopess/array_bind_004-2.mem - same, but with > valgrind > patched > http://gcov.php.net/viewer.php?version=PHP_5_2&func=valgrind&file=ext%2Foci8%2Ftests%2Farray_bind_004.phpt - > report from the test suite, but with suppressions > > It is strange that the bug that is bugging me ("Invalid read of size 8") > only appears when the tests are run through the test suite. The test suite > runs a slight different command that the one I was running. > I simply run: > valgrind ./sapi/cli/php ext/oci8/tests/array_bind_004.php > vg1.txt 2>&1 correction: the patched valgrind does suppress the invalid read of size 8 warning. Together with my suppressions file, now the test suite reports zero valgrind warnings :) Anyway the _intel_fast_memcmp warning is still there, but it is not problematic as I can suppress it. So, the patch seems to work :) Thanks, Nuno |
|
From: Nuno L. <nun...@sa...> - 2007-01-11 14:46:07
|
>> > which also contains a suggested fix, near the end. Can you let me >> > know whether this helps for you. >> >> My problem is unrelated with _intel_fast_memcpy. I had _intel_fast_memcmp >> generating warnings, but that on was easy to suppress (Memcheck:Cond\n >> fun:_intel_fast_memcmp). >> My problem is that valgrind isn't fetching the function name (maybe >> because >> it isn't global, as it lookups the _intel_fast_memcmp symbol correctly). > > I am not convinced the root cause is _intel_fast_memcmp. It might be, or > there might be multiple problems here. Did you try the change I > suggested? I have now tried it, but the _intel_fast_memcmp warnings still appear. reports without suppressions: http://gcov.php.net/~nlopess/vg1.txt - test execution with valgrind 3.2.1 http://gcov.php.net/~nlopess/vg2.txt - same, but with your patch http://gcov.php.net/~nlopess/array_bind_004.mem - execution of the test through our test suite http://gcov.php.net/~nlopess/array_bind_004-2.mem - same, but with valgrind patched http://gcov.php.net/viewer.php?version=PHP_5_2&func=valgrind&file=ext%2Foci8%2Ftests%2Farray_bind_004.phpt - report from the test suite, but with suppressions It is strange that the bug that is bugging me ("Invalid read of size 8") only appears when the tests are run through the test suite. The test suite runs a slight different command that the one I was running. I simply run: valgrind ./sapi/cli/php ext/oci8/tests/array_bind_004.php > vg1.txt 2>&1 The test suite: valgrind -q --tool=memcheck --trace-children=yes --log-file-exactly=/p2/var/php_gcov/PHP_5_2/ext/oci8/tests/array_bind_003.mem /p2/var/php_gcov/PHP_5_2/sapi/cli/php -f /p2/var/php_gcov/PHP_5_2/ext/oci8/tests/array_bind_004.php" 2>&1 So, is it the pipe forwarding that is causing the problems? the --log-file--exactly? really strange.. > Do you have a way I can reproduce this for further investigation here? > That would be the most helpful. Well it is not that easy for you to reproduce it.. This envolves compiling php with the oracle libs (which are free) and running a php test case, as the one found in the page mentioned above. I can provide you the binaries, but even so you would need an oracle server (XE is free as well) to connect to. Nuno |
|
From: Nicholas N. <nj...@cs...> - 2007-01-11 21:55:47
|
On Thu, 11 Jan 2007, Nuno Lopes wrote:
> It is strange that the bug that is bugging me ("Invalid read of size 8")
> only appears when the tests are run through the test suite. The test suite
> runs a slight different command that the one I was running.
> I simply run:
> valgrind ./sapi/cli/php ext/oci8/tests/array_bind_004.php > vg1.txt 2>&1
>
> The test suite:
> valgrind -q --tool=memcheck --trace-children=yes --log-file-exactly=/p2/var/php_gcov/PHP_5_2/ext/oci8/tests/array_bind_003.mem
> /p2/var/php_gcov/PHP_5_2/sapi/cli/php -f
> /p2/var/php_gcov/PHP_5_2/ext/oci8/tests/array_bind_004.php" 2>&1
>
> So, is it the pipe forwarding that is causing the problems?
> the --log-file--exactly? really strange..
Probably the --trace-children=yes..
Nick
|
|
From: Nuno L. <nun...@sa...> - 2007-01-14 00:42:28
|
>> ==3786== Source and destination overlap in memcpy(0x644C2E8, 0x644C2E8, >> 10) >> ==3786== at 0x401DE80: _intel_fast_memcpy (mc_replace_strmem.c:116) > > In r6509 (trunk) / r6512 (3_2_BRANCH) I fixed a bug in reading > icc9 generated debug info on amd64, and that has improved some of the > stack traces on amd64 for icc9 generated code. So if you are using amd64 > I suggest you check out the 3_2_BRANCH from the repo and work with that. Thanks, but ther server is x86. (about that error above, I get the stack trace. I didn't post it because I felt it wasn't interesting for you) >> We have already fixed many many bugs with valgrind's help :) > > Well, good! Don't forget to use cachegrind/callgrind to profile PHP > too. Yes, sure, at least I like Kcachegrind :) And are you suggesting by any means that PHP is slow? :P It is not that slow (especially newer php 5 versions) :) Nuno |
|
From: Josef W. <Jos...@gm...> - 2007-01-15 14:05:12
|
On Sunday 14 January 2007 00:37, Nuno Lopes wrote: > Yes, sure, at least I like Kcachegrind :) :-) If you have any suggestions how to improve it (both callgrind and KCachegrind), you are welcome. It's already some time since I last spent time into the GUI, but I need to make it work fine with Qt4 in the next time anyway, so... However, I'am not sure if I can misuse the valgrind mailing list for KCachegrind discussions ;-) Actually, I want it to be a frontend for multiple profile tools. There even exists a PHP profiler for it (not by me) ;-) Josef |
|
From: Julian S. <js...@ac...> - 2007-01-15 11:24:20
|
Nuno > ==3786== Source and destination overlap in memcpy(0x644C2E8, 0x644C2E8, 10) > ==3786== at 0x401DE80: _intel_fast_memcpy (mc_replace_strmem.c:116) In r6509 (trunk) / r6512 (3_2_BRANCH) I fixed a bug in reading icc9 generated debug info on amd64, and that has improved some of the stack traces on amd64 for icc9 generated code. So if you are using amd64 I suggest you check out the 3_2_BRANCH from the repo and work with that. > We have already fixed many many bugs with valgrind's help :) Well, good! Don't forget to use cachegrind/callgrind to profile PHP too. J |
|
From: Nuno L. <nun...@sa...> - 2007-01-15 18:51:45
|
> If you have any suggestions how to improve it (both callgrind > and KCachegrind), you are welcome. OK. I'll take note of your e-mail for future spamming :P > It's already some time since I last spent time into the GUI, but I need > to make it work fine with Qt4 in the next time anyway, so... > However, I'am not sure if I can misuse the valgrind mailing list for > KCachegrind discussions ;-) Actually, I want it to be a frontend for > multiple profile tools. > There even exists a PHP profiler for it (not by me) ;-) Actually there are two, both made by PHP core devs. One is Xdebug and the other is APD (advanced PHP debugger). Nuno |
|
From: Nuno L. <nun...@sa...> - 2007-01-15 19:49:26
|
> On Thu, 11 Jan 2007, Nuno Lopes wrote:
>
>> It is strange that the bug that is bugging me ("Invalid read of size 8")
>> only appears when the tests are run through the test suite. The test
>> suite
>> runs a slight different command that the one I was running.
>> I simply run:
>> valgrind ./sapi/cli/php ext/oci8/tests/array_bind_004.php > vg1.txt 2>&1
>>
>> The test suite:
>> valgrind -q --tool=memcheck --trace-children=yes --log-file-exactly=/p2/var/php_gcov/PHP_5_2/ext/oci8/tests/array_bind_003.mem
>> /p2/var/php_gcov/PHP_5_2/sapi/cli/php -f
>> /p2/var/php_gcov/PHP_5_2/ext/oci8/tests/array_bind_004.php" 2>&1
>>
>> So, is it the pipe forwarding that is causing the problems?
>> the --log-file--exactly? really strange..
>
> Probably the --trace-children=yes..
Uhm, that's a good explanation. php is single-threaded but sometimes libs
fork() by themselves..
Julian: the patch you provide in the bug report is great and it has already
caught a bug that was previously undetected :)
==3786== Source and destination overlap in memcpy(0x644C2E8, 0x644C2E8, 10)
==3786== at 0x401DE80: _intel_fast_memcpy (mc_replace_strmem.c:116)
<shameless plug>
I don't know if you have already take a look at the PHP testing site
(http://gcov.php.net), but we are using valgrind along with our test suite
to provide information to developers about memleaks, etc.. all those goodies
provided by valgrind :D We have already fixed many many bugs with valgrind's
help :)
</shameless plug>
Nuno
|
|
From: Nuno L. <nun...@sa...> - 2007-01-16 22:55:42
|
Sorry for bothering you again, but I think I found another problem.
Running a php+openssl test leads to the following:
==28855==
==28855== Use of uninitialised value of size 4
==28855== at 0x401DBC7: memcpy (mc_replace_strmem.c:406)
==28855== by 0x4588695: ASN1_STRING_set (in
/p2/usr/lib/i686/cmov/libcrypto.so.0.9.7)
{
<insert a suppression name here>
Memcheck:Value4
fun:memcpy
fun:ASN1_STRING_set
obj:*
obj:*
obj:*
obj:*
}
As I already have a suppression for libcrypto (below) I expected it to be
suppressed:
{
openssl2
Memcheck:Value4
obj:/p2/usr/lib/i686/cmov/libcrypto.so.*
}
Even so, I added that generated suppression (I tried with and without the
'obj:*'), but it doesn't suppress the error. There is also another warning
similar with this one that I can't suppress.
Is this a known problem or do you want me to send you more info for
debugging?
Thanks,
Nuno
|
|
From: Julian S. <js...@ac...> - 2007-01-16 23:05:17
|
Err, I lose track. Which version of V is this with?
J
On Tuesday 16 January 2007 22:54, Nuno Lopes wrote:
> Sorry for bothering you again, but I think I found another problem.
>
> Running a php+openssl test leads to the following:
>
> ==28855==
> ==28855== Use of uninitialised value of size 4
> ==28855== at 0x401DBC7: memcpy (mc_replace_strmem.c:406)
> ==28855== by 0x4588695: ASN1_STRING_set (in
> /p2/usr/lib/i686/cmov/libcrypto.so.0.9.7)
> {
> <insert a suppression name here>
> Memcheck:Value4
> fun:memcpy
> fun:ASN1_STRING_set
> obj:*
> obj:*
> obj:*
> obj:*
> }
>
>
> As I already have a suppression for libcrypto (below) I expected it to be
> suppressed:
> {
> openssl2
> Memcheck:Value4
> obj:/p2/usr/lib/i686/cmov/libcrypto.so.*
> }
>
> Even so, I added that generated suppression (I tried with and without the
> 'obj:*'), but it doesn't suppress the error. There is also another warning
> similar with this one that I can't suppress.
>
> Is this a known problem or do you want me to send you more info for
> debugging?
>
> Thanks,
> Nuno
|
|
From: Nuno L. <nun...@sa...> - 2007-01-16 23:35:20
|
Ah, sorry. It's valgrind 3.2.1 with a few patches provided by you (http://gcov.php.net/~nlopess/valgrind.diff.txt) Nuno ----- Original Message ----- > Err, I lose track. Which version of V is this with? > > J > > > On Tuesday 16 January 2007 22:54, Nuno Lopes wrote: >> Sorry for bothering you again, but I think I found another problem. >> >> Running a php+openssl test leads to the following: >> >> ==28855== >> ==28855== Use of uninitialised value of size 4 >> ==28855== at 0x401DBC7: memcpy (mc_replace_strmem.c:406) >> ==28855== by 0x4588695: ASN1_STRING_set (in >> /p2/usr/lib/i686/cmov/libcrypto.so.0.9.7) >> { >> <insert a suppression name here> >> Memcheck:Value4 >> fun:memcpy >> fun:ASN1_STRING_set >> obj:* >> obj:* >> obj:* >> obj:* >> } >> >> >> As I already have a suppression for libcrypto (below) I expected it to be >> suppressed: >> { >> openssl2 >> Memcheck:Value4 >> obj:/p2/usr/lib/i686/cmov/libcrypto.so.* >> } >> >> Even so, I added that generated suppression (I tried with and without the >> 'obj:*'), but it doesn't suppress the error. There is also another >> warning >> similar with this one that I can't suppress. >> >> Is this a known problem or do you want me to send you more info for >> debugging? >> >> Thanks, >> Nuno |
|
From: Ashley P. <as...@qu...> - 2007-01-18 17:17:47
|
On Sat, 2007-01-13 at 23:24 +0000, Julian Seward wrote: > Nuno > > > ==3786== Source and destination overlap in memcpy(0x644C2E8, 0x644C2E8, 10) > > ==3786== at 0x401DE80: _intel_fast_memcpy (mc_replace_strmem.c:116) > > In r6509 (trunk) / r6512 (3_2_BRANCH) I fixed a bug in reading > icc9 generated debug info on amd64, and that has improved some of the > stack traces on amd64 for icc9 generated code. So if you are using amd64 > I suggest you check out the 3_2_BRANCH from the repo and work with that. I've been reading this thread with interest, I've just done an update and quite a number of my tests now pass where they previously failed which I *think* is good, I'm assuming the function name is now being resolved to _intel_fast_memcpy() which is then being suppressed. A typical error would be one like the following, it's got the symptoms of a memcpy over-running it's source buffer slightly. RMS_RANK 0 Invalid read of size 8 at 0x4247BD8: (within /opt/ashley/nightly/quadrics/mpi/Linux_i686/mpi/mpi_intel/lib/libmpi.so.1.0) Address 0x68E1B18 is 576 bytes inside a block of size 583 alloc'd at 0x401B332: malloc (vg_replace_malloc.c:149) by 0x42154D0: MPID_UnpackMessageSetup (adi2mpack.c:78) by 0x4212DE4: MPID_IrecvDatatype (adi2hrecv.c:116) by 0x423461B: PMPI_Irecv (irecv.c:81) by 0x4280780: ADIOI_W_Exchange_data (ad_write_coll.c:652) by 0x427FC87: ADIOI_Exch_and_write (ad_write_coll.c:460) by 0x427EBD3: ADIOI_GEN_WriteStridedColl (ad_write_coll.c:198) by 0x42956D2: MPIOI_File_write_all (write_all.c:106) by 0x42952F6: PMPI_File_write_all (write_all.c:53) by 0x804FC01: IMB_write_indv (IMB_write.c:179) I'll know a lot more after the weekend when a full regression test has run but initial indications are that a lot of previously reported errors are now clean. Ashley, |
|
From: Julian S. <js...@ac...> - 2007-01-18 17:48:59
|
Ashley, thanks for the info. There were in total 3 fixes for icc9 generated code, all of which might have helped. > I'll know a lot more after the weekend when a full regression test has > run I'd be interested to hear if that confirms the results. J |
|
From: Ashley P. <as...@qu...> - 2007-01-22 15:40:48
|
On Thu, 2007-01-18 at 17:59 +0000, Julian Seward wrote: > Ashley, thanks for the info. There were in total 3 fixes for icc9 generated > code, all of which might have helped. > > > I'll know a lot more after the weekend when a full regression test has > > run > > I'd be interested to hear if that confirms the results. Mixed results, some tests are better and now pass, some remain unchanged since last week. A typical error is as follows: RMS_RANK 1 Invalid read of size 8 at 0x4275D18: (within /opt/ashley/nightly/quadrics/mpi/Linux_i686/mpi/mpi_intel/lib/libmpi.so.1.0) Address 0x5F27D18 is 0 bytes after a block of size 80 alloc'd at 0x401B636: malloc (vg_replace_malloc.c:207) by 0x4269B30: PMPI_Sendrecv_replace (sendrecv_rep.c:109) by 0x8051344: main (sndrcv.c:91) In this case there is the application and libmpio.so, both compiled with icc9.0. The PMPI_Sendrecv_replace() function is in the shared library, I don't know what function resides at 0x4275D18. Ashley, |
|
From: Julian S. <js...@ac...> - 2007-01-22 15:52:12
|
> A typical error is as follows: > > RMS_RANK 1 > Invalid read of size 8 > at 0x4275D18: (within > /opt/ashley/nightly/quadrics/mpi/Linux_i686/mpi/mpi_intel/lib/libmpi.so.1.0 Funny that there's no fn name here, particularly given that PMPI_Sendrecv_replace does have debug info and is also in the shared library (I presume you mean libmpi.so.1.0). Is this on x86 or amd64? J |