> -----Original Message----- > From: Vishal [mailto:vishal.ajm...@gmail.com] > Sent: Tuesday, July 30, 2013 1:05 AM > To: valgrind-users@lists.sourceforge.net > Subject: Re: [Valgrind-users] Valgrind throws assertion on powerpc while > trying to run 'ls' > > Paralkar Anmol-B07584 <B07584 <at> freescale.com> writes: > > > > > > -----Original Message----- > > > From: Vishal [mailto:vishal.ajmera <at> gmail.com] > > > Sent: Monday, July 29, 2013 1:40 PM > > > To: valgrind-users <at> lists.sourceforge.net > > > Subject: [Valgrind-users] Valgrind throws assertion on powerpc while > trying > > > to run 'ls' > > > > > > Hi, > > > > > > I am using valgrind 3.8.1 on powerpc. I could compile the valgrind > > > successfully however problem is when I try to run valgrind with any > command > > > I > > > get following error: > > > > > > $ valgrind ls > > > > > > valgrind: m_machine.c:1381 (vgPlain_machine_ppc32_set_clszB): Assertion > > > 'vai.ppc_cache_line_szB == 0 || vai.ppc_cache_line_szB == szB' failed. > > > > > > Can someone help me in correcting above problem? Is my installation > > > correct? > > > > > > Warm Regards, > > > Vishal > > > > Hi Vishal, > > > > What platform (PowerPC variant) are you on? > > > > There is an entry in Valgrind's KDE Bugtracking System: > > > > https://bugs.kde.org/show_bug.cgi?id=308135 > > > > - just in case it is relevant or it helps. > > > > Thanks, > > Anmol. > > > > Hi Anmol, > > I am using PPC476 FP variant. I looked at the bug posting but the assert > error mentioned in posting is at a different line then where I am getting > it > and so wondering if I had configured valgrind correctly. > > vg_assert(vai.ppc_cache_line_szB == 0 > || vai.ppc_cache_line_szB == szB); -- I get error at this > line. > > > vg_assert(szB == 32 || szB == 64 || szB == 128); -- posting in bugzilla > is > for this line. > > The two lines above are in the same function in m_machine.c one after > other. > > Note: when I comment the above line, compilation goes without error and I > could run valgrind. Is it safe to comment the above line which is giving > error? > > Warm Regards, > Vishal
Hi Vishal, I do not have a PPC476 FP system, so I cannot attempt to reproduce the issue. But, we need to understand what is going on. I tried this on the IBM POWER 7 system I have here at work (see log below). Please could you try the corresponding debug session on your PPC476 FP system? Note the comment in the code: "Either the value must not have been set yet (zero) or we can tolerate it being set to the same value multiple times, ..." In the log below, we see that vgPlain_machine_ppc64_set_clszB() is invoked twice before Valgrind/memcheck exits, each time with szB=128. What happens in your case? When vgPlain_machine_ppc32_set_clszB() is invoked for the first time, at entry time: Is vai.ppc_cache_line_szB == 0? What is the value of szB? Is vgPlain_machine_ppc32_set_clszB() invoked more than once? What value does vai.ppc_cache_line_szB hold each time? What value does szB hold each time? Essentially, why does: vai.ppc_cache_line_szB == 0 || vai.ppc_cache_line_szB == szB fail? Either at the first invocation vai.ppc_cache_line_szB != 0 or at a subsequent invocation, szB changes what already exists in vai.ppc_cache_line_szB - why? One other try: Likely, you are compiling Valgrind optimized by default. What if you compile it with optimization turned off: make CFLAGS="-O0 -g"? Does the assert still happen? Regards, Anmol. anmol:/proj/ppc/DT/labhome/anmol/valgrind-3.8.1> gdb bin/valgrind GNU gdb (GDB) Fedora (7.3.50.20110722-9.fc16) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "ppc64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /proj/.ppc_DT_labhome/labhome/anmol/valgrind-3.8.1/bin/valgrind...done. (gdb) add-inferior -exec lib/valgrind/memcheck-ppc64-linux Added inferior 2 Reading symbols from /proj/.ppc_DT_labhome/labhome/anmol/valgrind-3.8.1/lib/valgrind/memcheck-ppc64-linux...done. (gdb) inferior 2 [Switching to inferior 2 [process 0] (/proj/.ppc_DT_labhome/labhome/anmol/valgrind-3.8.1/lib/valgrind/memcheck-ppc64-linux)] (gdb) break vgPlain_machine_ppc64_set_clszB Breakpoint 1 at 0x38078354: file m_machine.c, line 1465. (gdb) inferior 1 [Switching to inferior 1 [process 0] (/proj/.ppc_DT_labhome/labhome/anmol/valgrind-3.8.1/bin/valgrind)] (gdb) run ~/hello Starting program: /proj/.ppc_DT_labhome/labhome/anmol/valgrind-3.8.1/bin/valgrind ~/hello process 7757 is executing new program: /proj/.ppc_DT_labhome/labhome/anmol/valgrind-3.8.1/lib/valgrind/memcheck-ppc64-linux Missing separate debuginfos, use: debuginfo-install glibc-2.14.90-24.fc16.7.ppc64 Breakpoint 1, vgPlain_machine_ppc64_set_clszB (szB=128) at m_machine.c:1465 1465 { (gdb) bt #0 vgPlain_machine_ppc64_set_clszB (szB=128) at m_machine.c:1465 #1 0x00000000380c82c4 in setup_client_stack (clstack_max_size=<optimized out>, clstack_end=34343026687, client_auxv=0x38f116e0, info=0x38f116e8, orig_envp=0x402010260, init_sp=0xfffffffeec0) at m_initimg/initimg-linux.c:725 #2 vgPlain_ii_create_image (iicii=...) at m_initimg/initimg-linux.c:930 #3 0x000000003807b748 in valgrind_main (argc=<optimized out>, argv=0xfffffffeec8, envp=0xfffffffeee0) at m_main.c:1852 #4 0x000000003807fb14 in _start_in_C_linux (pArgc=0xfffffffeec0) at m_main.c:2994 #5 0x0000000038078608 in ._start () (gdb) c Continuing. Breakpoint 1, vgPlain_machine_ppc64_set_clszB (szB=128) at m_machine.c:1465 1465 { (gdb) bt #0 vgPlain_machine_ppc64_set_clszB (szB=128) at m_machine.c:1465 #1 0x00000000380c82c4 in setup_client_stack (clstack_max_size=<optimized out>, clstack_end=34343026687, client_auxv=0x38f116e0, info=0x38f116e8, orig_envp=0x402010260, init_sp=0xfffffffeec0) at m_initimg/initimg-linux.c:725 #2 vgPlain_ii_create_image (iicii=...) at m_initimg/initimg-linux.c:930 #3 0x000000003807b748 in valgrind_main (argc=<optimized out>, argv=0xfffffffeec8, envp=0xfffffffeee0) at m_main.c:1852 #4 0x000000003807fb14 in _start_in_C_linux (pArgc=0xfffffffeec0) at m_main.c:2994 #5 0x0000000038078608 in ._start () (gdb) c Continuing. ==7822== Memcheck, a memory error detector ==7822== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==7822== Using Valgrind-3.8.1-FSL-SDK-1.4-spe-Fri-May-24-080638-PDT-2013 and LibVEX; rerun with -h for copyright info ==7822== Command: /home/anmol/hello ==7822== ==7822== Invalid write of size 4 ==7822== at 0x10000540: main (hello.c:8) ==7822== Address 0x4040044 is 0 bytes after a block of size 4 alloc'd ==7822== at 0x40281FC: malloc (vg_replace_malloc.c:270) ==7822== by 0x10000523: main (hello.c:6) ==7822== ==7822== ==7822== HEAP SUMMARY: ==7822== in use at exit: 4 bytes in 1 blocks ==7822== total heap usage: 1 allocs, 0 frees, 4 bytes allocated ==7822== ==7822== LEAK SUMMARY: ==7822== definitely lost: 4 bytes in 1 blocks ==7822== indirectly lost: 0 bytes in 0 blocks ==7822== possibly lost: 0 bytes in 0 blocks ==7822== still reachable: 0 bytes in 0 blocks ==7822== suppressed: 0 bytes in 0 blocks ==7822== Rerun with --leak-check=full to see details of leaked memory ==7822== ==7822== For counts of detected and suppressed errors, rerun with: -v ==7822== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) [Inferior 1 (process 7822) exited normally] (gdb) ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
