|
From: ian d. <id...@w9...> - 2004-10-06 17:41:09
|
Fedora Core 2, 2.6.8-1.251 kernel Valgrind 2.2.0 glib versions: # rpm -qa | grep -i glib glibc-common-2.3.3-27 glib2-2.4.0-1 dbus-glib-0.20-4.1 glibc-kernheaders-2.4-8.44 glibc-devel-2.3.3-27 glib2-devel-2.4.0-1 glibc-2.3.3-27 glib-1.2.10-12.1.1 glibc-headers-2.3.3-27 I'm trying to trace a parent application which spins off 3 threads. At a random amount of time, my program segfaults, and Valgrind was suggested to me as the tool to use to find out when/why/how my random crash is taking place since it had multi-threaded support. Unfortunately, after a few minutes of my program running it appears that Valgrind itself is crashing, and I get the following output as the last few lines of my log file. Command line arguments follow. valgrind: vg_memory.c:229 (vgPlain_unmap_range): Assertion `rs == s' failed. ==2004-10-05 18:09:37.273 3172== at 0xB002A954: vgPlain_skin_assert_fail (vg_mylibc.c:1137) ==2004-10-05 18:09:37.273 3172== by 0xB002A953: assert_fail (vg_mylibc.c:1133) ==2004-10-05 18:09:37.273 3172== by 0xB002A991: vgPlain_core_assert_fail (vg_mylibc.c:1144) ==2004-10-05 18:09:37.274 3172== by 0xB0028238: vgPlain_unmap_range (vg_memory.c:245) sched status: Thread 1: status = WaitSys, associated_mx = 0x0, associated_cv = 0x0 ==2004-10-05 18:09:37.274 3172== at 0x52BFF042: ??? ==2004-10-05 18:09:37.274 3172== by 0x3EFA64C: check_mouse_activity (lib_getch.c:70) ==2004-10-05 18:09:37.274 3172== by 0x3EFAB8E: _nc_wgetch (lib_getch.c:314) ==2004-10-05 18:09:37.274 3172== by 0x3EFACC7: wgetch (lib_getch.c:467) Thread 2: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==2004-10-05 18:09:37.274 3172== at 0x52BFF042: ??? ==2004-10-05 18:09:37.274 3172== by 0x243AFD: new_do_write (in /lib/tls/libc-2.3.3.so) ==2004-10-05 18:09:37.274 3172== by 0x243A95: _IO_do_write@@GLIBC_2.1 (in /lib/tls/libc-2.3.3.so) ==2004-10-05 18:09:37.274 3172== by 0x243397: _IO_file_close_it@@GLIBC_2.1 (in /lib/tls/libc-2.3.3.so) Thread 3: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==2004-10-05 18:09:37.274 3172== at 0x52BFF042: ??? ==2004-10-05 18:09:37.274 3172== by 0x243319: _IO_file_close_it@@GLIBC_2.1 (in /lib/tls/libc-2.3.3.so) ==2004-10-05 18:09:37.274 3172== by 0x239698: _IO_fclose@@GLIBC_2.1 (in /lib/tls/libc-2.3.3.so) ==2004-10-05 18:09:37.274 3172== by 0x804C571: ouoa_log (util.c:70) Thread 4: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==2004-10-05 18:09:37.274 3172== at 0x52BFF042: ??? ==2004-10-05 18:09:37.274 3172== by 0x243AFD: new_do_write (in /lib/tls/libc-2.3.3.so) ==2004-10-05 18:09:37.274 3172== by 0x243A95: _IO_do_write@@GLIBC_2.1 (in /lib/tls/libc-2.3.3.so) ==2004-10-05 18:09:37.274 3172== by 0x243397: _IO_file_close_it@@GLIBC_2.1 (in /lib/tls/libc-2.3.3.so) Command line arguments: # valgrind --tool=memcheck --log-file=/opt/ouoa/valgrind.txt \ --time-stamp=yes --error-limit=no --track-fds=yes \ --trace-sched=yes --trace-pthread=all --trace-malloc=no --run-libc-freeres=no --memcheck:leak-check=yes myprogram The source code is proprietary and cannot be given out for review at this point, and I understand that this fact alone could hinder getting a good answer. The entire log file is approximately 5.5MB uncompressed after running my application for only 20 minutes. 215Kb when bzip compressed. All I'm trying to accomplish right now is determine why my program crashes randomly; that is, which thread is crashing and why. If Valgrind is not the proper tool for this, please let me know which tool *is* appropriate. Currently, I'm trying to log as much as I can about every thread, including the parent, to see if I can pinpoint the problem, but have been unsuccessful as yet. Thanks for any assistance. -id |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2004-10-07 07:30:25
|
Hi, > I'm trying to trace a parent application which spins off 3 threads. At a > random amount of time, my program segfaults, and Valgrind was suggested to > me as the tool to use to find out when/why/how my random crash is taking > place since it had multi-threaded support. You may also try a debugger to start with. I use Totalview, but I think current versions of GDB do support threads. > Unfortunately, after a few minutes of my program running it appears that > Valgrind itself is crashing, and I get the following output as the last > few lines of my log file. Command line arguments follow. Are there any other messages before the crash? Dimitri |
|
From: Tom H. <th...@cy...> - 2004-10-07 07:51:59
|
In message <33569.65.125.162.119.1097081794.squirrel@65.125.162.119>
ian douglas <id...@w9...> wrote:
> Unfortunately, after a few minutes of my program running it appears that
> Valgrind itself is crashing, and I get the following output as the last
> few lines of my log file. Command line arguments follow.
>
> valgrind: vg_memory.c:229 (vgPlain_unmap_range): Assertion `rs == s' failed.
> ==2004-10-05 18:09:37.273 3172== at 0xB002A954:
> vgPlain_skin_assert_fail (vg_mylibc.c:1137)
> ==2004-10-05 18:09:37.273 3172== by 0xB002A953: assert_fail
> (vg_mylibc.c:1133)
> ==2004-10-05 18:09:37.273 3172== by 0xB002A991:
> vgPlain_core_assert_fail (vg_mylibc.c:1144)
> ==2004-10-05 18:09:37.274 3172== by 0xB0028238: vgPlain_unmap_range
> (vg_memory.c:245)
This is a bug in valgrind so please file a bug for it. It might be
helpful if you could increase the value of the num-callers option so
me can see more stack for the point where it fails.
It also be worth setting mem_debug to true in vg_memory.c and
rebuilding so you can attach the output from a run with that turned
on to the bug. That might be quite large though.
> Command line arguments:
>
> # valgrind --tool=memcheck --log-file=/opt/ouoa/valgrind.txt \
> --time-stamp=yes --error-limit=no --track-fds=yes \
> --trace-sched=yes --trace-pthread=all --trace-malloc=no
> --run-libc-freeres=no --memcheck:leak-check=yes myprogram
You've got several options set there which are only really intended
for use when debugging valgrind so I'd advise turning them off for now
as they will generate lot of output and not help much with finding
this bug in valgrind. I'm thinking of trace-sched and trace-pthread
in particular.
> All I'm trying to accomplish right now is determine why my program crashes
> randomly; that is, which thread is crashing and why. If Valgrind is not
> the proper tool for this, please let me know which tool *is* appropriate.
There is no magic tool to tell you why your program crashes. It may be
that valgrind will help you find or it may not - it rather depends on
what the cause of the crash is.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|