|
From: Brian S. <bs...@co...> - 2004-11-17 17:30:21
|
I am developing a cluster storage system and recently added a thread in = my server process to delete chunks outside the main loop. When I ran = the process using valgrind with the command line options: GLIBCPP_FORCE_NEW=3D1 valgrind --tool=3Dmemcheck --leak-check=3Dyes = --num-callers=3D8 --db-attach=3Dyes I ran the test on four separate servers, my test is very IO intensive. = After running for approximately four hours valgrind stopped on all four = servers running on independent platforms. All of the servers stopped = within 10 minutes of each other. Based on my application's output it = did not appear as if the new thread was in play at the time of the = stoppage (thread 3 below). I have run the process overnight using = valgrind in the past. I find the fact that all the servers quit at approximately the same time = to be curious. I'm hoping someone can tell me roughly what the = assertion means. I'm running valgrind 2.2.0 on Fedora Core 2 (2.6.5-1.358smp) Thanks, Brian Stark valgrind stopped on an assertion, the text message is below: 20041116-20:12:04 read 126602B from 66982262 count chunk size 65782262B. valgrind: vg_memory.c:229 (vgPlain_unmap_range): Assertion `rs =3D=3D s' = failed. =3D=3D15913=3D=3D at 0xB002A954: vgPlain_skin_assert_fail = (vg_mylibc.c:1137) =3D=3D15913=3D=3D by 0xB002A953: assert_fail (vg_mylibc.c:1133) =3D=3D15913=3D=3D by 0xB002A991: vgPlain_core_assert_fail = (vg_mylibc.c:1144) =3D=3D15913=3D=3D by 0xB0028238: vgPlain_unmap_range = (vg_memory.c:245) =3D=3D15913=3D=3D by 0xB0040F9C: after_munmap (vg_syscalls.c:4207) =3D=3D15913=3D=3D by 0xB0044AAF: vgPlain_post_syscall = (vg_syscalls.c:6339) =3D=3D15913=3D=3D by 0xB000D295: sched_do_syscall = (vg_scheduler.c:730) =3D=3D15913=3D=3D by 0xB000D90F: do_scheduler (vg_scheduler.c:1136) sched status: Thread 1: status =3D Runnable, associated_mx =3D 0x0, associated_cv =3D = 0x0 =3D=3D15913=3D=3D at 0x52BFF042: ??? =3D=3D15913=3D=3D by 0x85F319: _IO_file_close_it@@GLIBC_2.1 (in = /lib/tls/libc-2.3.3.so) =3D=3D15913=3D=3D by 0x855698: _IO_fclose@@GLIBC_2.1 (in = /lib/tls/libc-2.3.3.so) =3D=3D15913=3D=3D by 0x8052355: GetCPU (p_cpu.c:34) =3D=3D15913=3D=3D by 0x804A859: DoPING (srv.c:610) =3D=3D15913=3D=3D by 0x804AD3F: SendPING (srv.c:706) =3D=3D15913=3D=3D by 0x804BBF0: OpCheckIfFinished (srv.c:1129) =3D=3D15913=3D=3D by 0x804D4F5: NapHandleIO (srv.c:1641) Thread 2: status =3D WaitSys, associated_mx =3D 0x0, associated_cv =3D = 0x0 =3D=3D15913=3D=3D at 0x52BFF042: ??? =3D=3D15913=3D=3D by 0x80535AA: STSRVThread (stsrv.c:174) =3D=3D15913=3D=3D by 0x1B90CA07: thread_wrapper (vg_libpthread.c:867) =3D=3D15913=3D=3D by 0xB000EFE2: do__quit (vg_scheduler.c:1872) Thread 3: status =3D WaitCV, associated_mx =3D 0x1B943AD8, associated_cv = =3D 0x1B943AF0 =3D=3D15913=3D=3D at 0x1B90DED6: pthread_cond_wait = (vg_libpthread.c:1452) =3D=3D15913=3D=3D by 0x1B911C7D: sem_wait (vg_libpthread.c:2769) =3D=3D15913=3D=3D by 0x8054719: XSemaphoreDown (xthread.c:118) =3D=3D15913=3D=3D by 0x8054409: XQueuePop (xqueue.c:56) =3D=3D15913=3D=3D by 0x8049C23: DeleteThread (srv.c:129) =3D=3D15913=3D=3D by 0x1B90CA07: thread_wrapper (vg_libpthread.c:867) =3D=3D15913=3D=3D by 0xB000EFE2: do__quit (vg_scheduler.c:1872) Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: valgrind.kde.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. |
|
From: Tom H. <th...@cy...> - 2004-11-17 18:30:52
|
In message <CB1...@cb...>
"Brian Stark" <bs...@co...> wrote:
> I find the fact that all the servers quit at approximately the same time to
> be curious. I'm hoping someone can tell me roughly what the assertion
> means.
It means there is a bug in valgrind, that's what assertions always
mean. In this case it is bug 91028 which is fixed in CVS.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|