|
From: Brendan D. <bre...@pe...> - 2006-02-28 22:52:51
|
Some context: I'm trying to use valgrind to diagnose code delivered by a
subcontractor. Normally, I'd just look to see if I can get things to run
for "useably long periods" (just over two hours of video in this case,
or about 15k frames). However, since having discovered a show-stopper
memory bug in the last release, I've been quite a bit more wary about
what I will and will not accept in a build. As a result, I've written a
program which links against the library supplied by the subcontractor
and just exercises their subsystem. When I run Valgrind now, it
regularly breaks with the following message:
valgrind: m_mallocfree.c:170 (mk_plain_bszB): Assertion 'bszB != 0' failed.
==12850== at 0xB000ECCA: report_and_quit (m_libcassert.c:122)
==12850== by 0xB000EE66: vgPlain_assert_fail (m_libcassert.c:185)
==12850== by 0xB0016931: vgPlain_arena_malloc (m_mallocfree.c:170)
==12850== by 0xB0017151: vgPlain_arena_memalign (m_mallocfree.c:1202)
==12850== by 0xB002C150: vgPlain_cli_malloc (replacemalloc_core.c:103)
==12850== by 0xB0001D1F: vgMAC_memalign (mac_malloc_wrappers.c:192)
==12850== by 0xB002D90E: do_client_request (scheduler.c:995)
==12850== by 0xB002D36B: vgPlain_scheduler (scheduler.c:721)
==12850== by 0xB003BAE9: thread_wrapper (syswrap-linux.c:86)
==12850== by 0xB003BBAD: run_a_thread_NORETURN (syswrap-linux.c:119)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==12850== at 0x401C8CF: memalign (vg_replace_malloc.c:332)
==12850== by 0x40F6817: av_malloc (in /usr/local/lib/libavcodec-CVS.so)
==12850== by 0x40F4A40: av_mallocz (in /usr/local/lib/libavcodec-CVS.so)
==12850== by 0x406461D: (within /usr/local/lib/libavformat-CVS.so)
==12850== by 0x4064D3F: av_interleaved_write_frame (in
/usr/local/lib/libavformat-CVS.so)
==12850== by 0x804FB13: (within /usr/local/bin/ffmpeg)
==12850== by 0x80528D3: main (in /usr/local/bin/ffmpeg)
I assume that what the FAQ says about:
3.2. My (buggy) program dies like this:
% valgrind: vg_malloc2.c:442 (bszW_to_pszW): Assertion 'pszW >= 0'
failed.
applies -- is this correct?
If that is the case, is there any way to either instrument the code
(either mechanically or by hand) so as to try to protect Valgrind's
memory system?
Is there anything I can do to try to force symptoms of this problem to
become bad enough quickly enough so that it is detected closer to the
source of the bug?
Are there any _particular_ symptoms or patterns in the code that I
should be looking for to diagnose this problem?
I've noticed that when this program executes under gdb instead of
valgrind, it gets further than valgrind but eventually dies with a
corrupted stack and a segfault (this may or may not be pertinent
information).
Any thoughts or suggestions are greatly appreciated!
Thanks!
--
Brendan Drew
Research Scientist
PercepTek, Inc.
12395 North Mead Way
Littleton, CO 80125
Tel: 720-344-1037 x 126
Fax: 720-344-2360
|
|
From: Nicholas N. <nj...@cs...> - 2006-02-28 23:53:19
|
On Tue, 28 Feb 2006, Brendan Drew wrote: > valgrind: m_mallocfree.c:170 (mk_plain_bszB): Assertion 'bszB != 0' failed. > > I assume that what the FAQ says about: > > 3.2. My (buggy) program dies like this: > > % valgrind: vg_malloc2.c:442 (bszW_to_pszW): Assertion 'pszW >= 0' failed. > > applies -- is this correct? Probably. > If that is the case, is there any way to either instrument the code (either > mechanically or by hand) so as to try to protect Valgrind's memory system? > > Is there anything I can do to try to force symptoms of this problem to become > bad enough quickly enough so that it is detected closer to the source of the > bug? As the FAQ says, if it is a heap block overrun problem Memcheck should report some invalid write before the crash. You haven't said if it does. > Are there any _particular_ symptoms or patterns in the code that I should be > looking for to diagnose this problem? Heap block overruns. In short, what the FAQ says. Nick |
|
From: Brendan D. <bre...@pe...> - 2006-03-01 00:11:03
|
[snip] > As the FAQ says, if it is a heap block overrun problem Memcheck should > report some invalid write before the crash. You haven't said if it does. > >> Are there any _particular_ symptoms or patterns in the code that I >> should be looking for to diagnose this problem? > > Heap block overruns. > > In short, what the FAQ says. > > Nick There were invalid reads and writes prior to that point. Are there things I can do to try to protect the stack and the heap (like passing -fmud-flapth -lmudflap to GCC as I'm compiling and linking) inside Valgrind? Or at least have things blow up closer to where the actual source of the bug is? Without having access to the code which causes these issues, I'm quickly running out of good ideas -- any suggestions would be greatly appreciated. Thanks, Brendan. -- Brendan Drew Research Scientist PercepTek, Inc. 12395 North Mead Way Littleton, CO 80125 Tel: 720-344-1037 x 126 Fax: 720-344-2360 |
|
From: Dennis L. <pla...@in...> - 2006-03-01 00:55:37
|
Am Dienstag, den 28.02.2006, 17:10 -0700 schrieb Brendan Drew: > Valgrind? Or at least have things blow up closer to where the actual > source of the bug is? Without having access to the code which causes > these issues, I'm quickly running out of good ideas -- any suggestions > would be greatly appreciated. Print the code out on 120g DINA4 paper, glue it together, slap the author of the bug causing code with it. If that didnt help, the real error is in one of the beforementioned errors. If you dont have the ability to fix them, youre out of luck and should report it to those who wrote the erreneous code. greets Dennis |