|
From: Richa M. <ric...@gm...> - 2012-02-18 00:01:11
|
Hi, I am a valgrind user, and while running valgrind on my program, it got stuck on one of my library files. Following is the output of the running valgrind: --2990-- Considering /usr/lib/mylib.so.debug .. --2990-- .. CRC is valid The above statements are the last 2 statements of the whole output. Valgrind gets stuck here everytime and doesn't move forward. Please help with the issue. Thank you |
|
From: Philippe W. <phi...@sk...> - 2012-02-18 00:17:52
|
On Fri, 2012-02-17 at 16:01 -0800, Richa Mehta wrote: > Hi, > > > I am a valgrind user, and while running valgrind on my program, it got > stuck on one of my library files. > Following is the output of the running valgrind: > > > --2990-- Considering /usr/lib/mylib.so.debug .. > --2990-- .. CRC is valid > > > The above statements are the last 2 statements of the whole output. > Valgrind gets stuck here everytime and doesn't move forward. > Please help with the issue. With the above info, very difficult to see what is happening. Which version of Valgrind are you using ? On which OS ? If you do not use a recent valgrind (3.7.0), it is always better to try with the last version. If it still blocks, try to run it with -v -v -v -d -d -d to have some more trace and/or put some more debug flags (see valgrind --help-debug) Philippe |
|
From: Richa M. <ric...@gm...> - 2012-02-23 02:43:13
|
Hi, The valgrind version is: *valgrind-3.6.1* and the Linux OS is based off of: *montavista* I first connect to a virtual machine (VM), boot up my build image without starting any services. Then I run valgrind on my process, (only after starting all the services on which my process is dependent, so there is no dependency issue) Now, once the valgrind runs, it gets hung. I tried using all the flags including -d, -v, --leakcheck, etc once it gets hung, I am not even able to access the log file. I also tried to ssh to the vm which runs valgrind and the only thing I could figure out fro it is 2 to 3 processes taking more space... I don't think this will be of any help Can u plz guide me as to how to access the log file of valgrind, once it gets hung. Atleast that might give me some info as to which thread is causing the problem. On Fri, Feb 17, 2012 at 4:18 PM, Philippe Waroquiers < phi...@sk...> wrote: > On Fri, 2012-02-17 at 16:01 -0800, Richa Mehta wrote: > > Hi, > > > > > > I am a valgrind user, and while running valgrind on my program, it got > > stuck on one of my library files. > > Following is the output of the running valgrind: > > > > > > --2990-- Considering /usr/lib/mylib.so.debug .. > > --2990-- .. CRC is valid > > > > > > The above statements are the last 2 statements of the whole output. > > Valgrind gets stuck here everytime and doesn't move forward. > > Please help with the issue. > With the above info, very difficult to see what is happening. > > Which version of Valgrind are you using ? > On which OS ? > > If you do not use a recent valgrind (3.7.0), it is always better > to try with the last version. > > If it still blocks, try to run it with -v -v -v -d -d -d > to have some more trace and/or put some more debug flags > (see valgrind --help-debug) > > Philippe > > > > -- *Regards* *Richa Mehta* *MS, Computer Engineering* *Santa Clara University* |
|
From: David C. <dcc...@ac...> - 2012-02-23 03:12:30
|
On 2/22/2012 6:43 PM, Richa Mehta wrote:
> Hi,
>
> The valgrind version is: *valgrind-3.6.1*
> and the Linux OS is based off of: *montavista*
>
> I first connect to a virtual machine (VM), boot up my build image
> without starting any services.
> Then I run valgrind on my process, (only after starting all the
> services on which my process is dependent, so there is no dependency
> issue)
> Now, once the valgrind runs, it gets hung.
>
> I tried using all the flags including -d, -v, --leakcheck, etc
> once it gets hung, I am not even able to access the log file.
>
> I also tried to ssh to the vm which runs valgrind and the only thing I
> could figure out fro it is 2 to 3 processes taking more space...
> I don't think this will be of any help
>
> Can u plz guide me as to how to access the log file of valgrind, once
> it gets hung. Atleast that might give me some info as to which thread
> is causing the problem.
>
What happens if you launch valgrind on the command "ls -l"? Does
valgrind fail every time on the VM, or just on your program?
--
David Chapman dcc...@ac...
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
|
|
From: Richa M. <ric...@gm...> - 2012-02-23 18:26:46
|
Hi the output of valgrind ls -l is: ************************************************************************************************************ [172:~]$ /usr/bin/valgrind ls -l ==2096== Memcheck, a memory error detector ==2096== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==2096== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==2096== Command: ls -l ==2096== total 5296 -rwxr-xr-x 1 root root 2119 Feb 17 20:21 STARTMYPROC -rwxr-xr-x 1 root root 3107672 Feb 17 20:21 _mydope.so -rwxr-xr-x 1 root root 23211 Feb 17 20:21 mydope.py -rwxr-xr-x 1 root root 23173 Feb 17 21:21 mydope.pyo -rwxrwxr-- 1 root root 3432 Feb 20 21:01 stack-mgr.log -rwxr-xr-x 1 root root 23859 Feb 17 20:21 stack_mgr.py ==2096== Invalid free() / delete / delete[] ==2096== at 0x48CE3E8: free (replace_malloc.c:366) ==2096== by 0x4A10B1B: free_mem (in /mylib/libc-2.11.1.so) ==2096== by 0x4A10659: __libc_freeres (in /mylib/libc-2.11.1.so) ==2096== by 0x48C8493: _vgnU_freeres (preloaded.c:62) ==2096== by 0x4996AA7: _Exit (_exit.S:30) ==2096== Address 0x48cae00 is not stack'd, malloc'd or (recently) free'd ==2096== ==2096== ==2096== HEAP SUMMARY: ==2096== in use at exit: 12,656 bytes in 20 blocks ==2096== total heap usage: 105 allocs, 86 frees, 23,131 bytes allocated ==2096== ==2096== LEAK SUMMARY: ==2096== definitely lost: 0 bytes in 0 blocks ==2096== indirectly lost: 0 bytes in 0 blocks ==2096== possibly lost: 0 bytes in 0 blocks ==2096== still reachable: 12,656 bytes in 20 blocks ==2096== suppressed: 0 bytes in 0 blocks ==2096== Rerun with --leak-check=full to see details of leaked memory ==2096== ==2096== For counts of detected and suppressed errors, rerun with: -v ==2096== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 22 from 9) [172:~]$ ****************************************************************************************************************** This shows that valgrind is working properly.... On Wed, Feb 22, 2012 at 7:12 PM, David Chapman <dcc...@ac...> wrote: > On 2/22/2012 6:43 PM, Richa Mehta wrote: > > Hi, > > The valgrind version is: *valgrind-3.6.1* > and the Linux OS is based off of: *montavista* > > I first connect to a virtual machine (VM), boot up my build image without > starting any services. > Then I run valgrind on my process, (only after starting all the services > on which my process is dependent, so there is no dependency issue) > Now, once the valgrind runs, it gets hung. > > I tried using all the flags including -d, -v, --leakcheck, etc > once it gets hung, I am not even able to access the log file. > > I also tried to ssh to the vm which runs valgrind and the only thing I > could figure out fro it is 2 to 3 processes taking more space... > I don't think this will be of any help > > Can u plz guide me as to how to access the log file of valgrind, once it > gets hung. Atleast that might give me some info as to which thread is > causing the problem. > > > What happens if you launch valgrind on the command "ls -l"? Does valgrind > fail every time on the VM, or just on your program? > > -- > David Chapman dcc...@ac... > Chapman Consulting -- San Jose, CA > Software Development Done Right. > www.chapman-consulting-sj.com > > -- *Regards* *Richa Mehta* *MS, Computer Engineering* *Santa Clara University* |
|
From: Richa M. <ric...@gm...> - 2012-02-23 03:22:27
|
It fails only on my process.. Rest of the other processes work very fine wid valgrind. So, the problem is not with VM.. Sent from my iPhone On Feb 22, 2012, at 7:12 PM, David Chapman <dcc...@ac...> wrote: > On 2/22/2012 6:43 PM, Richa Mehta wrote: >> >> Hi, >> >> The valgrind version is: valgrind-3.6.1 >> and the Linux OS is based off of: montavista >> >> I first connect to a virtual machine (VM), boot up my build image without starting any services. >> Then I run valgrind on my process, (only after starting all the services on which my process is dependent, so there is no dependency issue) >> Now, once the valgrind runs, it gets hung. >> >> I tried using all the flags including -d, -v, --leakcheck, etc >> once it gets hung, I am not even able to access the log file. >> >> I also tried to ssh to the vm which runs valgrind and the only thing I could figure out fro it is 2 to 3 processes taking more space... >> I don't think this will be of any help >> >> Can u plz guide me as to how to access the log file of valgrind, once it gets hung. Atleast that might give me some info as to which thread is causing the problem. >> > > What happens if you launch valgrind on the command "ls -l"? Does valgrind fail every time on the VM, or just on your program? > -- > David Chapman dcc...@ac... > Chapman Consulting -- San Jose, CA > Software Development Done Right. > www.chapman-consulting-sj.com |
|
From: Dan K. <da...@ke...> - 2012-02-23 04:32:17
|
What CPU are you using? Can you valgrind /bin/true successfully? |
|
From: John R. <jr...@bi...> - 2012-02-23 05:36:31
|
> --2990-- Considering /usr/lib/mylib.so.debug .. > --2990-- .. CRC is valid > > The above statements are the last 2 statements of the whole output. Valgrind gets stuck here everytime ... > The valgrind version is: *valgrind-3.6.1* > and the Linux OS is based off of: *montavista* You haven't said what hardware architecture (x86, ARM, PowerPC, MIPS xxxx, etc.), or which compiler/linker/runtime system (gcc, icc, xcc, ..., glibc, uClibc, ...) you are using. Please tell us. Based on what you did say, it is somewhat likely that valgrind got confused by the debugging info in your executable program. Find a program which prints out *every* piece of debug info (symbol table, line numbers, types of variables, etc.), and run such a dumper on mylib.so.debug. Candidates are: readelf --debug-dump, objdump --debugging, etc. Attach the output to a bug report. Also, try running with no debug info: for instance, by using mylib.so instead of mylib.so.debug. -- |
|
From: Julian S. <js...@ac...> - 2012-02-23 07:26:05
|
On Thursday, February 23, 2012, John Reiser wrote: > > --2990-- Considering /usr/lib/mylib.so.debug .. > > --2990-- .. CRC is valid > > > > Based on what you did say, it is somewhat likely that valgrind got confused > by the debugging info in your executable program. Find a program which > prints out *every* piece of debug info (symbol table, line numbers, types > of variables, etc.), and run such a dumper on mylib.so.debug. Try V with --trace-syscalls=yes --trace-symtab=yes --trace-symtab-patt=/usr/lib/mylib.so.debug to get it to dump debuginfo for your program and also system calls. Let it run until it hangs and post the last 20 lines of the output here. J |
|
From: Richa M. <ric...@gm...> - 2012-02-23 18:53:49
|
Hi, Here's the required output *[172:~]$ /usr/bin/valgrind --trace-syscalls=yes --trace-symtab=yes --trace-syb-patt=/usr/lib/mylib.so.debug /usr/bin/myprog* *==2944== Memcheck, a memory error detector* *==2944== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.* *==2944== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info* *==2944== Command: /usr/bin/myprog* *==2944==* *Last 20 lines are:* * * SYSCALL[2948,1]( 5) sys_open ( 0xfe8394d0(/usr/lib/mylib.so), 0 ) --> [async] ... SYSCALL[2948,1]( 5) ... [async] --> Failure(0x2) SYSCALL[2948,1]( 5) sys_open ( 0xfe8394d0(/usr/lib/mylib.so), 0 ) --> [async] ... SYSCALL[2948,1]( 5) ... [async] --> Success(0x0:0x3) SYSCALL[2948,1]( 3) sys_read ( 3, 0xfe83960c, 512 ) --> [async] ... SYSCALL[2948,1]( 3) ... [async] --> Success(0x0:0x200) SYSCALL[2948,1](197) sys_fstat64 ( 3, 0xfe839530 )[sync] --> Success(0x0:0x0) SYSCALL[2948,1]( 90) old_mmap ( 0x0, 87352, 5, 2050, 3, 0 ) --> [pre-success] Success(0x0:0x49ba000) SYSCALL[2948,1]( 90) old_mmap ( 0x49ce000, 8192, 3, 2066, 3, 77824 ) --> [pre-success] Success(0x0:0x49ce000) SYSCALL[2948,1]( 6) sys_close ( 3 )[sync] --> Success(0x0:0x0) SYSCALL[2948,1]( 5) sys_open ( 0xfe8394b0(/lib/mylib_mgr.so), 0 ) --> [async] ... SYSCALL[2948,1]( 5) ... [async] --> Failure(0x2) SYSCALL[2948,1]( 5) sys_open ( 0xfe8394b0(/usr/lib/mylib_mgr.so), 0 ) --> [async] ... SYSCALL[2948,1]( 5) ... [async] --> Failure(0x2) SYSCALL[2948,1]( 5) sys_open ( 0xfe8394b0(/usr/lib/mylib_mgr.so), 0 ) --> [async] ... SYSCALL[2948,1]( 5) ... [async] --> Success(0x0:0x3) SYSCALL[2948,1]( 3) sys_read ( 3, 0xfe8395f0, 512 ) --> [async] ... SYSCALL[2948,1]( 3) ... [async] --> Success(0x0:0x200) SYSCALL[2948,1](197) sys_fstat64 ( 3, 0xfe839514 )[sync] --> Success(0x0:0x0) SYSCALL[2948,1]( 90) old_mmap ( 0x0, 263356, 5, 2050, 3, 0 ) --> [pre-success] Success(0x0:0x49d0000) SYSCALL[2948,1]( 90) old_mmap ( 0x4a0e000, 12288, 3, 2066, 3, 253952 ) Here it gets hung... Thanks, Richa On Wed, Feb 22, 2012 at 11:24 PM, Julian Seward <js...@ac...> wrote: > On Thursday, February 23, 2012, John Reiser wrote: > > > --2990-- Considering /usr/lib/mylib.so.debug .. > > > --2990-- .. CRC is valid > > > > > > > Based on what you did say, it is somewhat likely that valgrind got > confused > > by the debugging info in your executable program. Find a program which > > prints out *every* piece of debug info (symbol table, line numbers, types > > of variables, etc.), and run such a dumper on mylib.so.debug. > > Try V with > --trace-syscalls=yes > --trace-symtab=yes --trace-symtab-patt=/usr/lib/mylib.so.debug > to get it to dump debuginfo for your program and also system > calls. Let it run until it hangs and post the last 20 lines > of the output here. > > J > > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- *Regards* *Richa Mehta* *MS, Computer Engineering* *Santa Clara University* |