valgrind-users — General discussion list for Valgrind users

[Valgrind-users] Assertion failure in valgrind on Nvidia libGL - even with __GL_FORCE_GENERIC_CPU=1

[Alan C. <ala...@ya...>]

Hello all,

I couldn't find an archive so I hope this question
hasn't repeated too many times.  I am trying to run
our game with valgrind and have an assertion failure
trying to run it or even other GL applications such as
glxgears.  I read the FAQ and set the
GL_FORCE_GENERIC_CPU flag to one but this does not
help.  Has anyone else seen this?

I am running on RH9.0 and have tried 1.0-4349 and
1.0-4363 of the NVIDIA drivers.  A log is shown below
with the assertion failure.

Any help would be greatly appreciated!

-Alan

==17581== Memcheck, a.k.a. Valgrind, a memory error
detector for x86-linux.
==17581== Copyright (C) 2002, and GNU GPL'd, by Julian
Seward.
==17581== Using valgrind-1.9.6, a program
instrumentation system for x86-linux.
==17581== Copyright (C) 2000-2002, and GNU GPL'd, by
Julian Seward.
==17581== Estimated CPU clock rate is 1470 MHz
==17581== For more details, rerun with: -v
==17581==

valgrind: vg_ldt.c:167 (vgPlain_do_useseg): Assertion
`(seg_selector & 7) == 7' failed.

sched status:

Thread 1: status = Runnable, associated_mx = 0x0,
associated_cv = 0x0
==17581==    at 0x402D6601: __nvsym17670 (in
/usr/lib/tls/libGL.so.1.0.4363)


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

Re: [Valgrind-users] valgrind pthreads mutex bug

[Jeremy F. <je...@go...>]

On Sat, 2003-05-31 at 03:15, Igmar Palsenberg wrote:

> On Fri, 29 May 2003, Jeremy Fitzhardinge wrote:
> 
> > They're already useless for that; I'm guessing you really want to be
> > using condition variables, which have the behaviour you're looking for. 
> > With any luck, they synchronization code is only in one or two places...
> 
> I don't agree, they're used to protect global variables from having 
> multiple threads messing with then ...


I think we're violently agreeing on that.


> That requires kernel patching and a complete glibc rebuild :)
> 
> Just to wonder OT : Can both LinuxThreads and NTPL be build into the same 
> glibc ??


RH9 seems to have things set up so you can run either version.

    J

Re: [Valgrind-users] missing syscall: 252

[Michael V. <mv...@cs...>]

Glad to hear it ;-)  I didn't want to move to the unstable distribution
just for this.  I installed it and all is working smoothly again.
Thanks for your help!

Mike


> Date: Mon, 2 Jun 2003 10:32:49 +1000
> From: Benjamin Lee <ben...@re...>
> 
> One correction... the Debian package is found in testing not unstable.
> 
> testing/main valgrind 1.9.6-1 [785kB]
> 
> On Monday, 2003-06-02 at 10:26:20 AM, Benjamin Lee scribbled:
> > Stranger still.
> > 
> > Anyway, I just thought I'd check... but it seems 1.9.6 has support for
> > __NR_exit_group.
> > 
> > [Mon,  2 Jun 2003 10:19:08 +1000] Home Sweet Home
> > [ben@pov:/var/local/ben/a/valgrind-1.9.6]$ find -type f | xargs grep -n __NR_exit_group
> > ./coregrind/vg_syscalls.c:470:#     if defined(__NR_exit_group)
> > ./coregrind/vg_syscalls.c:471:      case __NR_exit_group:
> > ./coregrind/vg_scheduler.c:1472:#               if defined(__NR_exit_group)
> > ./coregrind/vg_scheduler.c:1473:                || VG_(threads)[tid].m_eax == __NR_exit_group
> > ./coregrind/vg_scheduler.c:1511:#                   if defined(__NR_exit_group)
> > ./coregrind/vg_scheduler.c:1512:                    && VG_(threads)[tid].m_eax != __NR_exit_group
> > [Mon,  2 Jun 2003 10:19:21 +1000] Home Sweet Home
> > [ben@pov:/var/local/ben/a/valgrind-1.9.6]$
> > 
> > 
> > I'd suggest using Debian sid/unstable with dselect to install valgrind
> > 1.9.6 rather than bother with compiling your own.
> > 
> > But I'd say the problem will definitely be mismatched headers.
> > 
> > 
> > 
> > 
> > 
> > Also... I checked my CVS files...
> > 
> > [Mon,  2 Jun 2003 10:15:20 +1000] Home Sweet Home
> > [ben@pov:~/cvsremote/valgrind]$ cvs status ./coregrind/vg_syscalls.c ./coregrind/vg_scheduler.c
> > ===================================================================
> > File: vg_syscalls.c     Status: Up-to-date
> > 
> >    Working revision:    1.34
> >    Repository revision: 1.34    /cvsroot/valgrind/valgrind/coregrind/vg_syscalls.c,v
> >    Sticky Tag:          (none)
> >    Sticky Date:         (none)
> >    Sticky Options:      (none)
> > 
> > ===================================================================
> > File: vg_scheduler.c    Status: Up-to-date
> > 
> >    Working revision:    1.126
> >    Repository revision: 1.126   /cvsroot/valgrind/valgrind/coregrind/vg_scheduler.c,v
> >    Sticky Tag:          (none)
> >    Sticky Date:         (none)
> >    Sticky Options:      (none)
> > 
> > [Mon,  2 Jun 2003 10:15:39 +1000] Home Sweet Home
> > [ben@pov:~/cvsremote/valgrind]$
> > 
> > 
> > [Mon,  2 Jun 2003 10:13:29 +1000] Home Sweet Home
> > [ben@pov:~/cvsremote/valgrind]$ grep -n 252 /usr/include/asm/unistd.h
> > 259:#define __NR_exit_group             252
> > [Mon,  2 Jun 2003 10:13:55 +1000] Home Sweet Home
> > [ben@pov:~/cvsremote/valgrind]$ find -type f | xargs grep -n __NR_exit_group
> > ./coregrind/vg_scheduler.c:1479:#               if defined(__NR_exit_group)
> > ./coregrind/vg_scheduler.c:1480:                || VG_(threads)[tid].m_eax == __NR_exit_group
> > ./coregrind/vg_scheduler.c:1518:#                   if defined(__NR_exit_group)
> > ./coregrind/vg_scheduler.c:1519:                    && VG_(threads)[tid].m_eax != __NR_exit_group
> > ./coregrind/vg_syscalls.c:470:#     if defined(__NR_exit_group)
> > ./coregrind/vg_syscalls.c:471:      case __NR_exit_group:
> > [Mon,  2 Jun 2003 10:14:17 +1000] Home Sweet Home
> > [ben@pov:~/cvsremote/valgrind]$
> > 
> > 
> > On Monday, 2003-06-02 at 06:44:23 AM, Michael Vanier scribbled:
> > > 
> > > Hmmm... just downloaded and compiled the CVS version of valgrind.  I get
> > > the same bug wrt syscall 252.  I looked in vg_syscalls.c and there is no
> > > mention of system call 252.
> > > 
> > > Mike
> > > 
> > > > Date: Mon, 2 Jun 2003 06:07:49 +1000
> > > > From: Benjamin Lee <ben...@re...>
> > > > 
> > > > Another guess... maybe the compile was using the wrong kernel headers?
> > > > 
> > > > On Monday, 2003-06-02 at 05:26:49 AM, Michael Vanier scribbled:
> > > > > 
> > > > > Curious... I *tried* to do that but gave up after many attempts and went
> > > > > back to 2.4.17 (at least I thought so...).  Anyway, thanks for the advice.
> > > > > 
> > > > > Mike
> > > > > 
> > > > > > From: Benjamin Lee <ben...@re...>
> > > > > > Date: Mon, 2 Jun 2003 05:03:52 +1000
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > The new syscall __NR_exit_group / 252 was added to kernel 2.4.20. I'd guess
> > > > > > you probably just upgraded your Debian Linux kernel from 2.4.18 to 2.4.20
> > > > > > using sid/unstable.
> > > > > > 
> > > > > > Roll yourself a valgrind from CVS and you'll be fine.
> > > > > > 
> > > > > > On Sunday, 2003-06-01 at 07:42:43 PM, Michael Vanier scribbled:
> > > > > > > 
> > > > > > > I just upgraded my valgrind installation to 1.9.6 from 1.9.5, and I
> > > > > > > immediately ran into a major problem.  I can't run valgrind any more
> > > > > > > because of a missing system call.  To add insult to injury, the number of
> > > > > > > the call (252) is not listed in /usr/include/asm/unistd.h.  Recompiling
> > > > > > > 1.9.5 fails as well with the same message, so presumably it's happening
> > > > > > > because the version of gcc/g++ I'm using has changed (I'm running gcc/g++
> > > > > > > 3.2.3 on a Debian Linux system).  Any advice/hints?
> > > > > > > 
> > > > > > > Mike
> > > > > > > 
> 
> -- 
> Benjamin Lee
> Melbourne, Australia             "Always real."    http://realthought.net/
> 
> __________________________________________________________________________
> 	"I assure you the thought never even crossed my mind, lord."
> 	"Indeed?  Then if I were you I'd sue my face for slander."
> 		-- Terry Pratchett, "The Colour of Magic"
> 

Re: [Valgrind-users] missing syscall: 252

[Benjamin L. <ben...@re...>]

One correction... the Debian package is found in testing not unstable.

testing/main valgrind 1.9.6-1 [785kB]

On Monday, 2003-06-02 at 10:26:20 AM, Benjamin Lee scribbled:
> Stranger still.
> 
> Anyway, I just thought I'd check... but it seems 1.9.6 has support for
> __NR_exit_group.
> 
> [Mon,  2 Jun 2003 10:19:08 +1000] Home Sweet Home
> [ben@pov:/var/local/ben/a/valgrind-1.9.6]$ find -type f | xargs grep -n __NR_exit_group
> ./coregrind/vg_syscalls.c:470:#     if defined(__NR_exit_group)
> ./coregrind/vg_syscalls.c:471:      case __NR_exit_group:
> ./coregrind/vg_scheduler.c:1472:#               if defined(__NR_exit_group)
> ./coregrind/vg_scheduler.c:1473:                || VG_(threads)[tid].m_eax == __NR_exit_group
> ./coregrind/vg_scheduler.c:1511:#                   if defined(__NR_exit_group)
> ./coregrind/vg_scheduler.c:1512:                    && VG_(threads)[tid].m_eax != __NR_exit_group
> [Mon,  2 Jun 2003 10:19:21 +1000] Home Sweet Home
> [ben@pov:/var/local/ben/a/valgrind-1.9.6]$
> 
> 
> I'd suggest using Debian sid/unstable with dselect to install valgrind
> 1.9.6 rather than bother with compiling your own.
> 
> But I'd say the problem will definitely be mismatched headers.
> 
> 
> 
> 
> 
> Also... I checked my CVS files...
> 
> [Mon,  2 Jun 2003 10:15:20 +1000] Home Sweet Home
> [ben@pov:~/cvsremote/valgrind]$ cvs status ./coregrind/vg_syscalls.c ./coregrind/vg_scheduler.c
> ===================================================================
> File: vg_syscalls.c     Status: Up-to-date
> 
>    Working revision:    1.34
>    Repository revision: 1.34    /cvsroot/valgrind/valgrind/coregrind/vg_syscalls.c,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)
> 
> ===================================================================
> File: vg_scheduler.c    Status: Up-to-date
> 
>    Working revision:    1.126
>    Repository revision: 1.126   /cvsroot/valgrind/valgrind/coregrind/vg_scheduler.c,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)
> 
> [Mon,  2 Jun 2003 10:15:39 +1000] Home Sweet Home
> [ben@pov:~/cvsremote/valgrind]$
> 
> 
> [Mon,  2 Jun 2003 10:13:29 +1000] Home Sweet Home
> [ben@pov:~/cvsremote/valgrind]$ grep -n 252 /usr/include/asm/unistd.h
> 259:#define __NR_exit_group             252
> [Mon,  2 Jun 2003 10:13:55 +1000] Home Sweet Home
> [ben@pov:~/cvsremote/valgrind]$ find -type f | xargs grep -n __NR_exit_group
> ./coregrind/vg_scheduler.c:1479:#               if defined(__NR_exit_group)
> ./coregrind/vg_scheduler.c:1480:                || VG_(threads)[tid].m_eax == __NR_exit_group
> ./coregrind/vg_scheduler.c:1518:#                   if defined(__NR_exit_group)
> ./coregrind/vg_scheduler.c:1519:                    && VG_(threads)[tid].m_eax != __NR_exit_group
> ./coregrind/vg_syscalls.c:470:#     if defined(__NR_exit_group)
> ./coregrind/vg_syscalls.c:471:      case __NR_exit_group:
> [Mon,  2 Jun 2003 10:14:17 +1000] Home Sweet Home
> [ben@pov:~/cvsremote/valgrind]$
> 
> 
> On Monday, 2003-06-02 at 06:44:23 AM, Michael Vanier scribbled:
> > 
> > Hmmm... just downloaded and compiled the CVS version of valgrind.  I get
> > the same bug wrt syscall 252.  I looked in vg_syscalls.c and there is no
> > mention of system call 252.
> > 
> > Mike
> > 
> > > Date: Mon, 2 Jun 2003 06:07:49 +1000
> > > From: Benjamin Lee <ben...@re...>
> > > 
> > > Another guess... maybe the compile was using the wrong kernel headers?
> > > 
> > > On Monday, 2003-06-02 at 05:26:49 AM, Michael Vanier scribbled:
> > > > 
> > > > Curious... I *tried* to do that but gave up after many attempts and went
> > > > back to 2.4.17 (at least I thought so...).  Anyway, thanks for the advice.
> > > > 
> > > > Mike
> > > > 
> > > > > From: Benjamin Lee <ben...@re...>
> > > > > Date: Mon, 2 Jun 2003 05:03:52 +1000
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > The new syscall __NR_exit_group / 252 was added to kernel 2.4.20. I'd guess
> > > > > you probably just upgraded your Debian Linux kernel from 2.4.18 to 2.4.20
> > > > > using sid/unstable.
> > > > > 
> > > > > Roll yourself a valgrind from CVS and you'll be fine.
> > > > > 
> > > > > On Sunday, 2003-06-01 at 07:42:43 PM, Michael Vanier scribbled:
> > > > > > 
> > > > > > I just upgraded my valgrind installation to 1.9.6 from 1.9.5, and I
> > > > > > immediately ran into a major problem.  I can't run valgrind any more
> > > > > > because of a missing system call.  To add insult to injury, the number of
> > > > > > the call (252) is not listed in /usr/include/asm/unistd.h.  Recompiling
> > > > > > 1.9.5 fails as well with the same message, so presumably it's happening
> > > > > > because the version of gcc/g++ I'm using has changed (I'm running gcc/g++
> > > > > > 3.2.3 on a Debian Linux system).  Any advice/hints?
> > > > > > 
> > > > > > Mike
> > > > > > 

-- 
Benjamin Lee
Melbourne, Australia             "Always real."    http://realthought.net/

__________________________________________________________________________
	"I assure you the thought never even crossed my mind, lord."
	"Indeed?  Then if I were you I'd sue my face for slander."
		-- Terry Pratchett, "The Colour of Magic"

Re: [Valgrind-users] missing syscall: 252

[Benjamin L. <ben...@re...>]

Stranger still.

Anyway, I just thought I'd check... but it seems 1.9.6 has support for
__NR_exit_group.

[Mon,  2 Jun 2003 10:19:08 +1000] Home Sweet Home
[ben@pov:/var/local/ben/a/valgrind-1.9.6]$ find -type f | xargs grep -n __NR_exit_group
./coregrind/vg_syscalls.c:470:#     if defined(__NR_exit_group)
./coregrind/vg_syscalls.c:471:      case __NR_exit_group:
./coregrind/vg_scheduler.c:1472:#               if defined(__NR_exit_group)
./coregrind/vg_scheduler.c:1473:                || VG_(threads)[tid].m_eax == __NR_exit_group
./coregrind/vg_scheduler.c:1511:#                   if defined(__NR_exit_group)
./coregrind/vg_scheduler.c:1512:                    && VG_(threads)[tid].m_eax != __NR_exit_group
[Mon,  2 Jun 2003 10:19:21 +1000] Home Sweet Home
[ben@pov:/var/local/ben/a/valgrind-1.9.6]$


I'd suggest using Debian sid/unstable with dselect to install valgrind
1.9.6 rather than bother with compiling your own.

But I'd say the problem will definitely be mismatched headers.





Also... I checked my CVS files...

[Mon,  2 Jun 2003 10:15:20 +1000] Home Sweet Home
[ben@pov:~/cvsremote/valgrind]$ cvs status ./coregrind/vg_syscalls.c ./coregrind/vg_scheduler.c
===================================================================
File: vg_syscalls.c     Status: Up-to-date

   Working revision:    1.34
   Repository revision: 1.34    /cvsroot/valgrind/valgrind/coregrind/vg_syscalls.c,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

===================================================================
File: vg_scheduler.c    Status: Up-to-date

   Working revision:    1.126
   Repository revision: 1.126   /cvsroot/valgrind/valgrind/coregrind/vg_scheduler.c,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

[Mon,  2 Jun 2003 10:15:39 +1000] Home Sweet Home
[ben@pov:~/cvsremote/valgrind]$


[Mon,  2 Jun 2003 10:13:29 +1000] Home Sweet Home
[ben@pov:~/cvsremote/valgrind]$ grep -n 252 /usr/include/asm/unistd.h
259:#define __NR_exit_group             252
[Mon,  2 Jun 2003 10:13:55 +1000] Home Sweet Home
[ben@pov:~/cvsremote/valgrind]$ find -type f | xargs grep -n __NR_exit_group
./coregrind/vg_scheduler.c:1479:#               if defined(__NR_exit_group)
./coregrind/vg_scheduler.c:1480:                || VG_(threads)[tid].m_eax == __NR_exit_group
./coregrind/vg_scheduler.c:1518:#                   if defined(__NR_exit_group)
./coregrind/vg_scheduler.c:1519:                    && VG_(threads)[tid].m_eax != __NR_exit_group
./coregrind/vg_syscalls.c:470:#     if defined(__NR_exit_group)
./coregrind/vg_syscalls.c:471:      case __NR_exit_group:
[Mon,  2 Jun 2003 10:14:17 +1000] Home Sweet Home
[ben@pov:~/cvsremote/valgrind]$


On Monday, 2003-06-02 at 06:44:23 AM, Michael Vanier scribbled:
> 
> Hmmm... just downloaded and compiled the CVS version of valgrind.  I get
> the same bug wrt syscall 252.  I looked in vg_syscalls.c and there is no
> mention of system call 252.
> 
> Mike
> 
> > Date: Mon, 2 Jun 2003 06:07:49 +1000
> > From: Benjamin Lee <ben...@re...>
> > 
> > Another guess... maybe the compile was using the wrong kernel headers?
> > 
> > On Monday, 2003-06-02 at 05:26:49 AM, Michael Vanier scribbled:
> > > 
> > > Curious... I *tried* to do that but gave up after many attempts and went
> > > back to 2.4.17 (at least I thought so...).  Anyway, thanks for the advice.
> > > 
> > > Mike
> > > 
> > > > From: Benjamin Lee <ben...@re...>
> > > > Date: Mon, 2 Jun 2003 05:03:52 +1000
> > > > 
> > > > Hi,
> > > > 
> > > > The new syscall __NR_exit_group / 252 was added to kernel 2.4.20. I'd guess
> > > > you probably just upgraded your Debian Linux kernel from 2.4.18 to 2.4.20
> > > > using sid/unstable.
> > > > 
> > > > Roll yourself a valgrind from CVS and you'll be fine.
> > > > 
> > > > On Sunday, 2003-06-01 at 07:42:43 PM, Michael Vanier scribbled:
> > > > > 
> > > > > I just upgraded my valgrind installation to 1.9.6 from 1.9.5, and I
> > > > > immediately ran into a major problem.  I can't run valgrind any more
> > > > > because of a missing system call.  To add insult to injury, the number of
> > > > > the call (252) is not listed in /usr/include/asm/unistd.h.  Recompiling
> > > > > 1.9.5 fails as well with the same message, so presumably it's happening
> > > > > because the version of gcc/g++ I'm using has changed (I'm running gcc/g++
> > > > > 3.2.3 on a Debian Linux system).  Any advice/hints?
> > > > > 
> > > > > Mike
> > > > > 
> > > > 
> > 
> > -- 
> > Benjamin Lee
> > Melbourne, Australia             "Always real."    http://realthought.net/
> > 
> > __________________________________________________________________________
> > Real Users know your home telephone number.
> > 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

-- 
Benjamin Lee
Melbourne, Australia             "Always real."    http://realthought.net/

__________________________________________________________________________
Don't worry about the world coming to an end today.  It's already tomorrow
in Australia.
		-- Charles Schulz

Re: [Valgrind-users] missing syscall: 252

[Michael V. <mv...@cs...>]

Hmmm... just downloaded and compiled the CVS version of valgrind.  I get
the same bug wrt syscall 252.  I looked in vg_syscalls.c and there is no
mention of system call 252.

Mike

> Date: Mon, 2 Jun 2003 06:07:49 +1000
> From: Benjamin Lee <ben...@re...>
> 
> Another guess... maybe the compile was using the wrong kernel headers?
> 
> On Monday, 2003-06-02 at 05:26:49 AM, Michael Vanier scribbled:
> > 
> > Curious... I *tried* to do that but gave up after many attempts and went
> > back to 2.4.17 (at least I thought so...).  Anyway, thanks for the advice.
> > 
> > Mike
> > 
> > > From: Benjamin Lee <ben...@re...>
> > > Date: Mon, 2 Jun 2003 05:03:52 +1000
> > > 
> > > Hi,
> > > 
> > > The new syscall __NR_exit_group / 252 was added to kernel 2.4.20. I'd guess
> > > you probably just upgraded your Debian Linux kernel from 2.4.18 to 2.4.20
> > > using sid/unstable.
> > > 
> > > Roll yourself a valgrind from CVS and you'll be fine.
> > > 
> > > On Sunday, 2003-06-01 at 07:42:43 PM, Michael Vanier scribbled:
> > > > 
> > > > I just upgraded my valgrind installation to 1.9.6 from 1.9.5, and I
> > > > immediately ran into a major problem.  I can't run valgrind any more
> > > > because of a missing system call.  To add insult to injury, the number of
> > > > the call (252) is not listed in /usr/include/asm/unistd.h.  Recompiling
> > > > 1.9.5 fails as well with the same message, so presumably it's happening
> > > > because the version of gcc/g++ I'm using has changed (I'm running gcc/g++
> > > > 3.2.3 on a Debian Linux system).  Any advice/hints?
> > > > 
> > > > Mike
> > > > 
> > > 
> 
> -- 
> Benjamin Lee
> Melbourne, Australia             "Always real."    http://realthought.net/
> 
> __________________________________________________________________________
> Real Users know your home telephone number.
> 

Re: [Valgrind-users] missing syscall: 252

[Benjamin L. <ben...@re...>]

For what it's worth...

ben@dbox:~$ dpkg -s libc6-dev
Package: libc6-dev
Status: install ok installed
Priority: standard
Section: libdevel
Installed-Size: 11748
Maintainer: GNU Libc Maintainers <deb...@li...>
Source: glibc
Version: 2.3.1-17
Replaces: man-db (<= 2.3.10-41), gettext (<= 0.10.26-1), ppp (<= 2.2.0f-24), libgdbmg1-dev (<= 1.7.3-24), ldso (<= 1.9.11-9), netkit-rpc, netbase (<< 4.0)
Provides: libc-dev
Depends: libc6 (= 2.3.1-17)
Recommends: c-compiler
Suggests: glibc-doc
Conflicts: libstdc++2.10-dev (<< 1:2.95.2-15), gcc-2.95 (<< 1:2.95.3-9), libpthread0-dev, libdl1-dev, libdb1-dev, libgdbm1-dev, libc6-dev (<< 2.0.110-1), locales (<< 2.1.3-5), libstdc++2.9-dev, netkit-rpc, libc-dev
Description: GNU C Library: Development Libraries and Header Files.
 Contains the symlinks, headers, and object files needed to compile
 and link programs which use the standard C library.

ben@dbox:~$ grep 252 /usr/include/asm/unistd.h
#define __NR_exit_group         252
ben@dbox:~$

ben@dbox:~/cvsremote/valgrind$ uname -a
Linux dbox 2.4.20-3-386 #1 Sun May 18 18:18:12 EST 2003 i686 GNU/Linux
ben@dbox:~/cvsremote/valgrind$

This box just compiled the latest CVS version, no problemo.

Good luck.
Cheers,
Ben.

On Monday, 2003-06-02 at 06:07:49 AM, Benjamin Lee scribbled:
> Another guess... maybe the compile was using the wrong kernel headers?
> 
> On Monday, 2003-06-02 at 05:26:49 AM, Michael Vanier scribbled:
> > 
> > Curious... I *tried* to do that but gave up after many attempts and went
> > back to 2.4.17 (at least I thought so...).  Anyway, thanks for the advice.
> > 
> > Mike
> > 
> > > From: Benjamin Lee <ben...@re...>
> > > Date: Mon, 2 Jun 2003 05:03:52 +1000
> > > 
> > > Hi,
> > > 
> > > The new syscall __NR_exit_group / 252 was added to kernel 2.4.20. I'd guess
> > > you probably just upgraded your Debian Linux kernel from 2.4.18 to 2.4.20
> > > using sid/unstable.
> > > 
> > > Roll yourself a valgrind from CVS and you'll be fine.
> > > 
> > > On Sunday, 2003-06-01 at 07:42:43 PM, Michael Vanier scribbled:
> > > > 
> > > > I just upgraded my valgrind installation to 1.9.6 from 1.9.5, and I
> > > > immediately ran into a major problem.  I can't run valgrind any more
> > > > because of a missing system call.  To add insult to injury, the number of
> > > > the call (252) is not listed in /usr/include/asm/unistd.h.  Recompiling
> > > > 1.9.5 fails as well with the same message, so presumably it's happening
> > > > because the version of gcc/g++ I'm using has changed (I'm running gcc/g++
> > > > 3.2.3 on a Debian Linux system).  Any advice/hints?
> > > > 
> > > > Mike
> > > > 
> > > 
> 
> -- 
> Benjamin Lee
> Melbourne, Australia             "Always real."    http://realthought.net/
> 
> __________________________________________________________________________
> Real Users know your home telephone number.

-- 
Benjamin Lee
Melbourne, Australia             "Always real."    http://realthought.net/

__________________________________________________________________________
Real Users know your home telephone number.

Re: [Valgrind-users] missing syscall: 252

[Benjamin L. <ben...@re...>]

Another guess... maybe the compile was using the wrong kernel headers?

On Monday, 2003-06-02 at 05:26:49 AM, Michael Vanier scribbled:
> 
> Curious... I *tried* to do that but gave up after many attempts and went
> back to 2.4.17 (at least I thought so...).  Anyway, thanks for the advice.
> 
> Mike
> 
> > From: Benjamin Lee <ben...@re...>
> > Date: Mon, 2 Jun 2003 05:03:52 +1000
> > 
> > Hi,
> > 
> > The new syscall __NR_exit_group / 252 was added to kernel 2.4.20. I'd guess
> > you probably just upgraded your Debian Linux kernel from 2.4.18 to 2.4.20
> > using sid/unstable.
> > 
> > Roll yourself a valgrind from CVS and you'll be fine.
> > 
> > On Sunday, 2003-06-01 at 07:42:43 PM, Michael Vanier scribbled:
> > > 
> > > I just upgraded my valgrind installation to 1.9.6 from 1.9.5, and I
> > > immediately ran into a major problem.  I can't run valgrind any more
> > > because of a missing system call.  To add insult to injury, the number of
> > > the call (252) is not listed in /usr/include/asm/unistd.h.  Recompiling
> > > 1.9.5 fails as well with the same message, so presumably it's happening
> > > because the version of gcc/g++ I'm using has changed (I'm running gcc/g++
> > > 3.2.3 on a Debian Linux system).  Any advice/hints?
> > > 
> > > Mike
> > > 
> > 

-- 
Benjamin Lee
Melbourne, Australia             "Always real."    http://realthought.net/

__________________________________________________________________________
Real Users know your home telephone number.

Re: [Valgrind-users] missing syscall: 252

[Benjamin L. <ben...@re...>]

Hi,

The new syscall __NR_exit_group / 252 was added to kernel 2.4.20. I'd guess
you probably just upgraded your Debian Linux kernel from 2.4.18 to 2.4.20
using sid/unstable.

Roll yourself a valgrind from CVS and you'll be fine.

On Sunday, 2003-06-01 at 07:42:43 PM, Michael Vanier scribbled:
> 
> I just upgraded my valgrind installation to 1.9.6 from 1.9.5, and I
> immediately ran into a major problem.  I can't run valgrind any more
> because of a missing system call.  To add insult to injury, the number of
> the call (252) is not listed in /usr/include/asm/unistd.h.  Recompiling
> 1.9.5 fails as well with the same message, so presumably it's happening
> because the version of gcc/g++ I'm using has changed (I'm running gcc/g++
> 3.2.3 on a Debian Linux system).  Any advice/hints?
> 
> Mike
> 

-- 
Benjamin Lee
Melbourne, Australia             "Always real."    http://realthought.net/

__________________________________________________________________________
Preudhomme's Law of Window Cleaning:
	It's on the other side.

Re: [Valgrind-users] Jump to the invalid address stted on the next line

[Nicholas N. <nj...@ca...>]

On Sat, 31 May 2003, Xiaolei Hao wrote:

> When I tried the valgrind with my problem, the valgrind always gets crashed
> with a "segmentation fault" as soon as I perfomed a particular operation.
> However, the program doesn't crash itself if it runs alone.

When you run your program under Valgrind, it's behaviour isn't preserved
exactly -- things like thread scheduling and memory layouts can be a bit
different.  Your original program might not crash due to luck.

Since the jump to 0x0 occurs from within _pthread_cleanup_pop, it looks
like you might have accidentally registered a NULL cleanup handler with
pthread_cleanup_push?  Could this have happened?  (If so, I'm not sure why
your program wouldn't crash normally... it might be a bug in Valgrind, but
I would try to fix the three errors Valgrind claims to see first.  Chances
are if you do that it won't crash under Valgrind anymore, and you can be
more confident it won't crash randomly when run normally.)

N

[Valgrind-users] missing syscall: 252

[Michael V. <mv...@cs...>]

I just upgraded my valgrind installation to 1.9.6 from 1.9.5, and I
immediately ran into a major problem.  I can't run valgrind any more
because of a missing system call.  To add insult to injury, the number of
the call (252) is not listed in /usr/include/asm/unistd.h.  Recompiling
1.9.5 fails as well with the same message, so presumably it's happening
because the version of gcc/g++ I'm using has changed (I'm running gcc/g++
3.2.3 on a Debian Linux system).  Any advice/hints?

Mike

[Valgrind-users] Jump to the invalid address stted on the next line

[Xiaolei H. <xh...@sc...>]

Hi, all,

When I tried the valgrind with my problem, the valgrind always gets =
crashed
with a "segmentation fault" as soon as I perfomed a particular =
operation.=20
However, the program doesn't crash itself if it runs alone. I highly =
suspect=20
something wrong with my problem, I just don't know what it is. The last=20
three pieces of valgrind commentary are interesting. Here they are:

=3D=3D24934=3D=3D Thread 23:
=3D=3D24934=3D=3D Invalid read of size 4
=3D=3D24934=3D=3D     at 0x842E800: PThread::PX_ThreadEnd(void*) =
(tlibthrd.cxx:1054)
=3D=3D24934=3D=3D     by 0x4027D836: _pthread_cleanup_pop =
(vg_libpthread.c:844)
=3D=3D24934=3D=3D     by 0x842E7E5: PThread::PX_ThreadStart(void*) =
(tlibthrd.cxx:1045)
=3D=3D24934=3D=3D     by 0x4027D41C: thread_wrapper =
(vg_libpthread.c:671)
=3D=3D24934=3D=3D     Address 0x4017E9FA4 is 40 bytes inside a block of =
size 141 free'd
=3D=3D24934=3D=3D     at 0x4015E5A5: free (vg_clientfuncs.c:185)
=3D=3D24934=3D=3D     by 0x8442CCE: PMemoryHeap::Deallocated(void*, char =
const*) (../common/object.cxx:647)
=3D=3D24934=3D=3D     by 0x831A62B:  H225TransportThread::operator =
delete(void*) (transports.cxx:466)
=3D=3D24934=3D=3D     by 0x8318D22:  =
H225TransportThread::~H225TransportThread() =
(/usr/include/c++/3.2/iostream:62)
=3D=3D24934=3D=3D=20
=3D=3D24934=3D=3D Thread 23:
=3D=3D24934=3D=3D Invalid read of size 4
=3D=3D24934=3D=3D     at 0x842E80B: PThread::PX_ThreadEnd(void*) =
(tlibthrd.cxx:1054)
=3D=3D24934=3D=3D     by 0x4027D836: _pthread_cleanup_pop =
(vg_libpthread.c:844)
=3D=3D24934=3D=3D     by 0x842E7E5: PThread::PX_ThreadStart(void*) =
(tlibthrd.cxx:1045)
=3D=3D24934=3D=3D     by 0x4027D41C: thread_wrapper =
(vg_libpthread.c:671)
=3D=3D24934=3D=3D     Address 0xA5A5A609 is not stack'd malloc'd or =
free'd
=3D=3D24934=3D=3D=20
=3D=3D24934=3D=3D Thread 23:
=3D=3D24934=3D=3D Jump to the invalid address stated on the next line
=3D=3D24934=3D=3D     at 0x0: ???
=3D=3D24934=3D=3D     by 0x4027D836: _pthread_cleanup_pop =
(vg_libpthread.c:844)
=3D=3D24934=3D=3D     by 0x842E7E5: PThread::PX_ThreadStart(void*) =
(tlibthrd.cxx:1045)
=3D=3D24934=3D=3D     by 0x4027D41C: thread_wrpper (vg_libpthread.c:671)
=3D=3D24934=3D=3D     Address 0x0 is not stack'd, malloc'd or free'd

I do understand, based on section 2.4 of valgrind documentation, that if =
"your=20
program attemps to read from address zero, the skin will emit a message =
to=20
this effect, and the program will then duly die with a segmentation =
fault". What=20
I don't understand is that why my program doesn't crash itself when it =
is running
alone. What should I do to get it working? Your advice is highly =
appreciated.

Lei

Re: [Valgrind-users] valgrind pthreads mutex bug

[Igmar P. <mai...@jd...>]

On Fri, 29 May 2003, Jeremy Fitzhardinge wrote:

> They're already useless for that; I'm guessing you really want to be
> using condition variables, which have the behaviour you're looking for. 
> With any luck, they synchronization code is only in one or two places...

I don't agree, they're used to protect global variables from having 
multiple threads messing with then :

pthread_mutex_lock(&mutex);

for (....;...;...) {
	/* Walk linked list*/
        .....
}
pthread_mutex_unlock(&mutex);

This works fine, at least in my app with at least 5 threads running, not 
counting incoming connections.

I use rwlocks whenever I can, that means you must be able to read a 
datastructure without modifying it.
cond. variables are the way to go when it comes to thread synchronisation, 
I use them to process an application shutdown.

I've seen weird things happening when valgrind monitors threads, including 
the SIGFPE's flying around :). I'll see if I can reproduce it again, I 
know what happened when those things started.

> > > The bug is that Valgrind should flag this as an error.
> > 
> > The whole cinelerra (quite a huge program) is based upon this kind of
> > behaviour. It uses mutexes in order to synchronize 'data delivery':
> 
> That's exactly what a condvar is for.

Indeed. Mutexes can't be used for that.
 
> > So my question is... would it be possible for Valgrind to support this
> > bugous behaviour by some switch or something?
> 
> If you come up with a patch we can look at it.  But I think your time
> would be better spent fixing the code: what you're asking is equivalent
> to "but my program always uses memory after it has been freed, and it
> works fine without Valgrind".
> 
> > The problem is that cinelerra works just fine if it is run without
> > valgrind... 
> 
> Oh yes. Have you tried it with NPTL?

That requires kernel patching and a complete glibc rebuild :)

Just to wonder OT : Can both LinuxThreads and NTPL be build into the same 
glibc ??

> 
>     J



	Igmar 

Re: [Valgrind-users] valgrind pthreads mutex bug

[Igmar P. <mai...@jd...>]

On Fri, 29 May 2003, Jeremy Fitzhardinge wrote:

> On Thu, 2003-05-29 at 16:23, Andraz Tori wrote:
> 
> > Maybe worth mentioning is, that thread 25 wasn't the thread that created
> > & locked the mutex at the first place, but this should not be an issue,
> > since this is vaild behaviour in pthreads.
> 
> No it isn't.  You can't lock with one thread and unlock with another -
> pthread_mutex_unlock should return EPERM (calling thread does not own
> mutex).

With a big if attached : The mutex should be created as a checking mutex. 
If you don't, things just hang / crash / do other weird stuff.

Use PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP instead of 
PTHREAD_MUTEX_INITIALIZER
 
> The bug is that Valgrind should flag this as an error.
> 
>     J

Indeed.


	Igmar
 

Re: [Valgrind-users] valgrind pthreads mutex bug

[Jeremy F. <je...@go...>]

On Thu, 2003-05-29 at 18:09, Andraz Tori wrote:

> The problem is that main maintainer has... mildly said ... strange
> attitutde towards any external work done. to my experience he would
> never accept external patch to fix this.


Ah well, that's unfortunate.


> Thanks ! But aren't condvars slower than mutexes? (i would imagine)


Don't know; I've never measured them.  But that's unimportant if mutexes
are the wrong mechanism to use.


> here it is, relevant part of the log file...
> mutex 0x41a9f2a4 is being unlocked, and perror says successefuly, on the
> next usage it blocks on lock...


OK, we should make valgrind mutexes more picky.

    J

Re: [Valgrind-users] valgrind pthreads mutex bug

[Andraz T. <And...@gu...>]

V pet, 30.05.2003 ob 02:32, je Jeremy Fitzhardinge poslal(a):
> On Thu, 2003-05-29 at 17:01, Andraz Tori wrote: 
> > Thanks, I didn't know that. De facto this is vaild behaviour in
> > pthreads... Everything works as expected if valgrind is not run...
> > 
> > If this is true than mutexes are useless for interthread synchronisation
> > of 'data ready' states?
> They're already useless for that; I'm guessing you really want to be
> using condition variables, which have the behaviour you're looking
> for.  With any luck, they synchronization code is only in one or two
> places...

I am afraid it is not so easy... Cinelerra is a strange beast...

kocka:/home/minmax/progs/hvirtual-1.1.6/cinelerra# grep Mutex *.[Ch]|wc
-l
    104

approx half of these mutexes is being used for synchronisation like this
and this does not include plugins ... :)

The problem is that main maintainer has... mildly said ... strange
attitutde towards any external work done. to my experience he would
never accept external patch to fix this. 

Heh... my other question is... would it be possible to modify valgrind
so it would not report memory leaks that occured just once (at the same
code line)?

Again, main maintainer isn't willing to make deletions on exit (even
when provided with a proper patch) so i am looking for some other
solution to be able to find just leaks that are done repeatedly while
using the program. There are houndrets of one-time leaks, so writing
supressions for all of them is out of the question...

> > > The bug is that Valgrind should flag this as an error.
> > 
> > The whole cinelerra (quite a huge program) is based upon this kind of
> > behaviour. It uses mutexes in order to synchronize 'data delivery':
> That's exactly what a condvar is for. 

Thanks ! But aren't condvars slower than mutexes? (i would imagine)

> > So my question is... would it be possible for Valgrind to support this
> > bugous behaviour by some switch or something?
> If you come up with a patch we can look at it.  But I think your time
> would be better spent fixing the code: what you're asking is
> equivalent to "but my program always uses memory after it has been
> freed, and it works fine without Valgrind". 

I would gladly fix the code, but i am afraid it wont be accepted into
main branch of cinelerra, which means the work would be useless. At
least to my experience. So I just try to work on trivial bugs, because
anything nontrivial isn't accepted.

> > The problem is that cinelerra works just fine if it is run without
> > valgrind... 
> Oh yes. Have you tried it with NPTL?

no, I am already afraid.  :)

but the bottom line: why don't neither pthreads neither valgrind return
the error on the unlock call... Valgrind reports a warning, but call
still returns success (perror says nothing)... even if it is obvious
there was a failure.

I did create error checking pthread mutex (as you suggest in your next
message)..  it is not reporting errors.

the unlock is done with:
	printf("Unlocking mutex: %p\n", &mutex);
	if(pthread_mutex_unlock(&mutex)) {perror("Mutex::unlock");

here it is, relevant part of the log file...
mutex 0x41a9f2a4 is being unlocked, and perror says successefuly, on the
next usage it blocks on lock...

Unlocking mutex: 0x41a9f2a4
--24562-- PTHREAD[25]: pthread_mutex_unlock	 mx 0x41A9F2A4 ...
--24562-- PTHREAD[25]: pthread_mutex_lock       mx 0x409BB1F0 ...
--24562-- PTHREAD[25]: pthread_mutex_unlock     mx 0x409BB1F0 ...
--24562-- PTHREAD[25]: pthread_mutex_lock       mx 0x409C28C8 ...
--24562-- PTHREAD[25]: pthread_mutex_unlock     mx 0x409C28C8 ...
--24562-- PTHREAD[25]: pthread_key_validate    key 0x3
--24562-- PTHREAD[25]: pthread_getspecific_ptr
--24562-- PTHREAD[25]: pthread_mutex_lock       mx 0x409BB1F0 ...
--24562-- PTHREAD[25]: pthread_mutex_unlock	mx 0x409BB1F0 ...
--24562-- PTHREAD[25]: pthread_mutex_lock  	mx 0x409BB1F0 ...
--24562-- PTHREAD[25]: pthread_mutex_unlock	mx 0x409BB1F0 ...
--24562-- PTHREAD[25]: pthread_mutex_lock  	mx 0x409C28C8 ...
--24562-- PTHREAD[25]: pthread_mutex_unlock	mx 0x409C28C8 ...
Mutex::unlock: Success   
Locking mutex: 0x41a9f2a4
--24562-- PTHREAD[25]: pthread_mutex_lock 	 mx 0x41A9F2A4 ...   
--24562-- PTHREAD[25]: pthread_mutex_lock 	 mx 0x41A9F2A4: BLOCK


bye
andraz

Re: [Valgrind-users] valgrind pthreads mutex bug

[Jeremy F. <je...@go...>]

On Thu, 2003-05-29 at 17:28, Andraz Tori wrote:

> well.. i don't know why it works. but fact is that the whole program
> (heavily multithreaded) is written in such manner, and up to now there
> were no problems with it...
> Maybe it is not what POSIX says, but it seems that it works... 

That's an illusion.  There's no certainty until you fix your code.  I
suspect that even if pthread mutexes were working in the way you think
they should, your code would still have race-conditions and/or be
deadlock-prone.

Condition variables are pretty easy to use: a pthread_cond_t is always
paired with a pthread_mutex_t.  To sleep on one, waiting for an event to
happen, you use:

        pthread_mutex_lock(&mutex);
        while(!test_condition()) {
        	// cond_wait() atomically released the mutex and
        	// goes to sleep on the condvar
        	pthread_cond_wait(&condvar, &mutex);
        }
        // act on event
        pthread_mutex_unlock(&mutex);

At the other end, when you want to generate your event, you do:

        pthread_mutex_lock(&mutex);
        set_condition_true();
        pthread_cond_signal(&condvar);	// or cond_broadcast()
        pthread_mutex_unlock(&mutex);
        
> Does this mean that pthreads do not do what they should? i don't know. I
> am not an expert, just an user with a problem, so i am sorry if i say
> something stupid. :)

By default pthread mutexes are "fast" which means they don't check for
errors, and don't report them; they just behave in undefined ways.  It
so happens in this case it seems to be behaving in the way you expect,
but you can't rely on it: someone might upgrade their library and
completely break the program.

If you create an error-checking pthread mutex, it should start reporting
errors.

        J

Re: [Valgrind-users] valgrind pthreads mutex bug

[Jeremy F. <je...@go...>]

On Thu, 2003-05-29 at 17:01, Andraz Tori wrote:

> Thanks, I didn't know that. De facto this is vaild behaviour in
> pthreads... Everything works as expected if valgrind is not run...
> 
> If this is true than mutexes are useless for interthread synchronisation
> of 'data ready' states?

They're already useless for that; I'm guessing you really want to be
using condition variables, which have the behaviour you're looking for. 
With any luck, they synchronization code is only in one or two places...


> > The bug is that Valgrind should flag this as an error.
> 
> The whole cinelerra (quite a huge program) is based upon this kind of
> behaviour. It uses mutexes in order to synchronize 'data delivery':

That's exactly what a condvar is for.

> So my question is... would it be possible for Valgrind to support this
> bugous behaviour by some switch or something?

If you come up with a patch we can look at it.  But I think your time
would be better spent fixing the code: what you're asking is equivalent
to "but my program always uses memory after it has been freed, and it
works fine without Valgrind".

> The problem is that cinelerra works just fine if it is run without
> valgrind... 

Oh yes. Have you tried it with NPTL?

    J

Re: [Valgrind-users] valgrind pthreads mutex bug

[Andraz T. <And...@gu...>]

V pet, 30.05.2003 ob 02:07, je Julian Seward poslal(a):
> > So my question is... would it be possible for Valgrind to support this
> > bugous behaviour by some switch or something?
> >
> > The problem is that cinelerra works just fine if it is run without
> > valgrind...
> 
> If what you say is true, then it only works by luck and is certainly
> not compliant the the POSIX pthread standard.  It sounds like you
> need to use the "condition variable" facility of POSIX pthreads to 
> achieve the "data ready" signalling you want, or perhaps the
> POSIX semaphore functions (sem_*).

well.. i don't know why it works. but fact is that the whole program
(heavily multithreaded) is written in such manner, and up to now there
were no problems with it...
Maybe it is not what POSIX says, but it seems that it works... 

i just added error checking
	if(pthread_mutex_unlock(&mutex)) printf("Mutex unlock error");

no error is ever reported (when not running under valgrind).
Valgrind reports warning, but returns success!

Does this mean that pthreads do not do what they should? i don't know. I
am not an expert, just an user with a problem, so i am sorry if i say
something stupid. :)

bye 
andraz

Re: [Valgrind-users] valgrind pthreads mutex bug

[Julian S. <js...@ac...>]

> So my question is... would it be possible for Valgrind to support this
> bugous behaviour by some switch or something?
>
> The problem is that cinelerra works just fine if it is run without
> valgrind...

If what you say is true, then it only works by luck and is certainly
not compliant the the POSIX pthread standard.  It sounds like you
need to use the "condition variable" facility of POSIX pthreads to 
achieve the "data ready" signalling you want, or perhaps the
POSIX semaphore functions (sem_*).

J

Re: [Valgrind-users] valgrind pthreads mutex bug

[Andraz T. <And...@gu...>]

V pet, 30.05.2003 ob 01:37, je Jeremy Fitzhardinge poslal(a):
> On Thu, 2003-05-29 at 16:23, Andraz Tori wrote: 
> > Maybe worth mentioning is, that thread 25 wasn't the thread that created
> > & locked the mutex at the first place, but this should not be an issue,
> > since this is vaild behaviour in pthreads.
> No it isn't.  You can't lock with one thread and unlock with another -
> pthread_mutex_unlock should return EPERM (calling thread does not own
> mutex).

Thanks, I didn't know that. De facto this is vaild behaviour in
pthreads... Everything works as expected if valgrind is not run...

If this is true than mutexes are useless for interthread synchronisation
of 'data ready' states?


> The bug is that Valgrind should flag this as an error.

The whole cinelerra (quite a huge program) is based upon this kind of
behaviour. It uses mutexes in order to synchronize 'data delivery':
When data is ready, the server thread unlocks A-'data ready for
processing mutex' and blocks on B-'data is processed mutex'. Before that
client thread is waiting on blocked A. When server thread unlocks it,
client thread can go on untill it finishes. When it finishes, it locks A
again, unlocks B, and locks (and this time blocks) on A again. Server
thread was waiting on blocking B and since it has now been unlocked by
client, it knows data is ready and can happily continue.

So my question is... would it be possible for Valgrind to support this
bugous behaviour by some switch or something?

The problem is that cinelerra works just fine if it is run without
valgrind... 

Bye
Andraz

Re: [Valgrind-users] Mismatched new/delete

[Jeremy F. <je...@go...>]

On Thu, 2003-05-29 at 14:56, Alex Ivershen wrote:

> Now, as you can see the allocation is done by __builtin_new, and
> deallocation by __builtin_delete - no mismatch here. What is strange
> though is that __builtin_delete is intercepted by valgrind, whereas
> __builtin_new goes into compiler and valgrind sees only malloc from
> there.  Quite naturally, it reports a mismatch in this case.  Does
> anyone know a reason why this is happening and how to fix it ? 

The problem is that Valgrind isn't intercepting __builtin_new, so its
using the compiler's version of it, which ends up calling malloc();
therefore, Valgrind sees the block as being allocated with malloc().  It
does successfully intercept __builtin_delete, so that's why it sees the
mismatch.

What compiler version are you using?  Are you linking with g++ (rather
than just plain gcc)?

    J

Re: [Valgrind-users] valgrind pthreads mutex bug

[Jeremy F. <je...@go...>]

On Thu, 2003-05-29 at 16:23, Andraz Tori wrote:

> Maybe worth mentioning is, that thread 25 wasn't the thread that created
> & locked the mutex at the first place, but this should not be an issue,
> since this is vaild behaviour in pthreads.

No it isn't.  You can't lock with one thread and unlock with another -
pthread_mutex_unlock should return EPERM (calling thread does not own
mutex).

The bug is that Valgrind should flag this as an error.

    J

[Valgrind-users] valgrind pthreads mutex bug

[Andraz T. <And...@gu...>]

I am trying to debug large heavily multithreaded program (Cinelerra)
with Valgrind, but i think i have found a bug in valgrind instead.

Basically, in one case locking mutex just after it was unlocked yields
mutex block.
Log is this:

Unlocking mutex: 0x491c3c70
--17547-- PTHREAD[25]: pthread_mutex_unlock	 mx 0x491C3C70 ...
Locking mutex: 0x491c3c70
--17547-- PTHREAD[25]: pthread_mutex_lock	 mx 0x491C3C70 ...
--17547-- PTHREAD[25]: pthread_mutex_lock	mx 0x491C3C70: BLOCK

No lines between were deleted, so this events happen one after another.
This is definitely wrong behaviour, as the lock after unlock should not
block.

I am using debian unstable, glibc 2.3.1, gcc 3.3
I tested this with valgrind 1.9.6 and with CVS version.

Maybe worth mentioning is, that thread 25 wasn't the thread that created
& locked the mutex at the first place, but this should not be an issue,
since this is vaild behaviour in pthreads.

Cinelerra uses mutex locking all over the place, but this behaviour is
100% reproducable - always happens with the same mutex.

Bye
Anrdaz

[Valgrind-users] Mismatched new/delete

[Alex I. <ale...@in...>]

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi all,
<p>I hope someone could give me a hand here - Valgrind is reporting mismatched
free/delete operation in one of my classes, however I am doing plain new
and matching delete.&nbsp; Here is a snippet of the log:
<p>==15083== Thread 24:
<br>==15083== Mismatched free() / delete / delete []
<br>==15083==&nbsp;&nbsp;&nbsp; at 0x4015E62D: __builtin_delete (vg_clientfuncs.c:199)
<br>==15083==&nbsp;&nbsp;&nbsp; by 0x4029059B: BTNode::~BTNode(void) (../src/BinTree.cpp:71)
<br>==15083==&nbsp;&nbsp;&nbsp; by 0x459D3F69: SymTableEntry::~SymTableEntry(void)
(../src/SymTable.cc:168)
<br>...
<br>==15083==&nbsp;&nbsp;&nbsp; Address 0x4480F42C is 0 bytes inside a
block of size 120 alloc'd
<br>==15083==&nbsp;&nbsp;&nbsp; at 0x4015E310: malloc (vg_clientfuncs.c:103)
<br>==15083==&nbsp;&nbsp;&nbsp; by 0x459D9CAB: __builtin_new (../../gcc-2.95.3/gcc/cp/new1.cc:77)
<br>==15083==&nbsp;&nbsp;&nbsp; by 0x459D3D8B: SymTable::Insert(char const
*, int, int, int) (../src/SymTable.cc:96)
<p>Now, as you can see the allocation is done by __builtin_new, and deallocation
by __builtin_delete - no mismatch here. What is strange though is that
__builtin_delete is intercepted by valgrind, whereas __builtin_new goes
into compiler and valgrind sees only malloc from there.&nbsp; Quite naturally,
it reports a mismatch in this case.&nbsp; Does anyone know a reason why
this is happening and how to fix it ?
<p>Thanks!
<br>Alex
<pre>--&nbsp;
Alex G. Ivershen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Inet Technologies, Inc.
Network Products Dept.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1500 N. Greenville Ave.
Inet Technologies Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Richardson, TX 75081
Phone: +1-469-330-4295&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; USA

"Black Holes are where God divided by zero"</pre>
&nbsp;</html>