Debian Bug report logs - #506239
SEGV in multithreaded program causes incorrect valgrind exit code

Reply or subscribe to this bug.

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Mike Crowe <mac@mcrowe.com>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: SEGV in multithreaded program causes incorrect valgrind exit code

Date: Wed, 19 Nov 2008 17:13:25 +0000

Package: valgrind
Version: 1:3.2.1-1
Severity: normal



-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.24-etchnhalf.1-686-bigmem
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages valgrind depends on:
ii  libc6                  2.3.6.ds1-13etch7 GNU C Library: Shared libraries

Versions of packages valgrind recommends:
ii  gdb                        6.4.90.dfsg-1 The GNU Debugger

-- no debconf information

Valgrind still returns with an exit code of zero when the following
program is run despite being called as "valgrind --error-exitcode=42".

The valgrind output also continues even after the shell prompt
returns.

I've reproduced this on etch using valgrind-3.2.1-1 and a backported
valgrind-3.3.1-2 from lenny. Occasionally valgrind behaves correctly
but most of the time it does not.

If I compile the original release valgrind-3.3.1 tarball myself then
it does not show either symptom.

I have no reason to believe that this problem is boost-specific. It
was just the easiest way for me to produce a minimal test case.


 #include <boost/thread.hpp>
 
 void CrashThread()
 {
     int *foo = reinterpret_cast<int *>(3);
     *foo = 42;
 }
 
 int main()
 {
     boost::thread thread(CrashThread);
     thread.join();
     return 0;
 }

Message #10 received at 506239@bugs.debian.org (full text, mbox, reply):

From: Mike Crowe <mac@mcrowe.com>

To: 506239@bugs.debian.org

Subject: valgrind output

Date: Wed, 19 Nov 2008 17:23:20 +0000

Here is the output from valgrind-3.2.1. The output from 3.3.1 is
similar. Notice the shell-prompt in the middle and the exit code at
the end.

repton:~/src/valgrind-bugs> valgrind --error-exitcode=42 vgt
==10322== Memcheck, a memory error detector.
==10322== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==10322== Using LibVEX rev 1658, a library for dynamic binary translation.
==10322== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==10322== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework.
==10322== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==10322== For more details, rerun with: -v
==10322==
==10323== Thread 2:
==10323== Conditional jump or move depends on uninitialised value(s)
==10323==    at 0x428A0CC: __pthread_manager (manager.c:128)
==10323==    by 0x42107F9: clone (clone.S:119)
==10323==
==10323== Syscall param clone(child_tidptr) contains uninitialised byte(s)
==10323==    at 0x42107EC: clone (clone.S:100)
==10323==    by 0x42107F9: clone (clone.S:119)
==10324==
==10324== Thread 3:
==10324== Invalid write of size 4
==10324==    at 0x8048724: CrashThread() (in /home/mac/src/valgrind-bugs/vgt)
==10324==    by 0x804896A: boost::detail::function::void_function_invoker0<void (*)(), void>::invoke(boost::detail::function::any_pointer) (in /home/mac/src/valgrind-bugs/vgt)
==10324==    by 0x403D03B: boost::function0<void, std::allocator<boost::function_base> >::operator()() const (in /usr/lib/libboost_thread-gcc-mt-1_33_1.so.1.33.1)
==10324==    by 0x403C9AF: (within /usr/lib/libboost_thread-gcc-mt-1_33_1.so.1.33.1)
==10324==    by 0x4289C50: pthread_start_thread (manager.c:310)
==10324==    by 0x42107F9: clone (clone.S:119)
==10324==  Address 0x3 is not stack'd, malloc'd or (recently) free'd
==10324==
==10324== Process terminating with default action of signal 11 (SIGSEGV)
==10324==  Access not within mapped region at address 0x3
==10324==    at 0x8048724: CrashThread() (in /home/mac/src/valgrind-bugs/vgt)
==10324==    by 0x804896A: boost::detail::function::void_function_invoker0<void (*)(), void>::invoke(boost::detail::function::any_pointer) (in /home/mac/src/valgrind-bugs/vgt)
==10324==    by 0x403D03B: boost::function0<void, std::allocator<boost::function_base> >::operator()() const (in /usr/lib/libboost_thread-gcc-mt-1_33_1.so.1.33.1)
==10324==    by 0x403C9AF: (within /usr/lib/libboost_thread-gcc-mt-1_33_1.so.1.33.1)
==10324==    by 0x4289C50: pthread_start_thread (manager.c:310)
==10324==    by 0x42107F9: clone (clone.S:119)
repton:~/src/valgrind-bugs> ==10323==
==10323== Thread 2:
==10323== Invalid read of size 4
==10323==    at 0x424AF7E: _nl_locale_subfreeres (setlocale.c:455)
==10323==    by 0x424ACD6: free_mem (gconv_db.c:792)
==10323==    by 0x424B431: __libc_freeres (set-freeres.c:47)
==10323==    by 0x40191F6: _vgnU_freeres (vg_preloaded.c:60)
==10323==    by 0x42DB2FF: ???
==10323==    by 0x42107F9: clone (clone.S:119)
==10323==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==10323==
==10323== Process terminating with default action of signal 11 (SIGSEGV)
==10323==  Access not within mapped region at address 0x0
==10323==    at 0x424AF7E: _nl_locale_subfreeres (setlocale.c:455)
==10323==    by 0x424ACD6: free_mem (gconv_db.c:792)
==10323==    by 0x424B431: __libc_freeres (set-freeres.c:47)
==10323==    by 0x40191F6: _vgnU_freeres (vg_preloaded.c:60)
==10323==    by 0x42DB2FF: ???
==10323==    by 0x42107F9: clone (clone.S:119)
==10323==
==10323== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 28 from 6)
==10323== malloc/free: in use at exit: 13,896 bytes in 5 blocks.
==10323== malloc/free: 5 allocs, 0 frees, 13,896 bytes allocated.
==10323== For counts of detected errors, rerun with: -v
==10323== searching for pointers to 5 not-freed blocks.
==10323== checked 8,815,656 bytes.
==10323==
==10323== LEAK SUMMARY:
==10323==    definitely lost: 0 bytes in 0 blocks.
==10323==      possibly lost: 5,736 bytes in 4 blocks.
==10323==    still reachable: 8,160 bytes in 1 blocks.
==10323==         suppressed: 0 bytes in 0 blocks.
==10323== Reachable blocks (those to which a pointer was found) are not shown.
==10323== To see them, rerun with: --show-reachable=yes

repton:~/src/valgrind-bugs> echo $?
0

Message #15 received at 506239@bugs.debian.org (full text, mbox, reply):

From: Alessandro Ghedini <al3xbio@gmail.com>

To: Mike Crowe <mac@mcrowe.com>, 506239@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Re: Bug#506239: SEGV in multithreaded program causes incorrect valgrind exit code

Date: Fri, 11 May 2012 15:51:07 +0200

[Message part 1 (text/plain, inline)]

tags 506239 moreinfo unreproducible
kthxbye

On Wed, Nov 19, 2008 at 05:13:25PM +0000, Mike Crowe wrote:
> Valgrind still returns with an exit code of zero when the following
> program is run despite being called as "valgrind --error-exitcode=42".
> 
> The valgrind output also continues even after the shell prompt
> returns.
> 
> I've reproduced this on etch using valgrind-3.2.1-1 and a backported
> valgrind-3.3.1-2 from lenny. Occasionally valgrind behaves correctly
> but most of the time it does not.
> 
> If I compile the original release valgrind-3.3.1 tarball myself then
> it does not show either symptom.
> 
> I have no reason to believe that this problem is boost-specific. It
> was just the easiest way for me to produce a minimal test case.
> 
> 
>  #include <boost/thread.hpp>
>  
>  void CrashThread()
>  {
>      int *foo = reinterpret_cast<int *>(3);
>      *foo = 42;
>  }
>  
>  int main()
>  {
>      boost::thread thread(CrashThread);
>      thread.join();
>      return 0;
>  }

I cannot reproduce this with the valgrind version in unstable. Does this still
happen to you?

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;<inidehG ordnasselA>;eg;say~~reverse'

[signature.asc (application/pgp-signature, inline)]

Message #22 received at 506239@bugs.debian.org (full text, mbox, reply):

From: Mike Crowe <mac@mcrowe.com>

To: 506239@bugs.debian.org

Cc: Alessandro Ghedini <al3xbio@gmail.com>

Subject: Re: Bug#506239: SEGV in multithreaded program causes incorrect valgrind exit code

Date: Fri, 25 May 2012 14:51:57 +0100

I've tested using:

 valgrind 1:3.6.0~svn11254+nmu1 (from squeeze)
 valgrind 1:3.7.0-5 (from sid)

Both yield an exit code of 137 rather rather than the requested 42
(which appears to disagree with the man page) but I don't really care
as long as it doesn't yield zero.

The original problem no longer occurs.

Thanks.

Mike.

Send a report that this bug log contains spam.