> > 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) >
Hi Anmol, I could not try GDB session as you suggested below. Unfortunately add- inferior command is not supported on our installation. I tried to put printf in the code but that gave vague errors. Next I tried to put some asserts at the same place like: 1. vg_assert(vai.ppc_cache_line_szB == 0) 2. vg_assert(vai.ppc_cache_line_szB == szB) 3. vg_assert(szB != 0) 4. vg_assert(szB != 32) 5. vg_assert(szB != 64) 6. vg_assert(szB != 128) The test failed again at line (2) above. Will this information help? Do you want me to try something else? Warm Regards, Vishal ------------------------------------------------------------------------------ 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