Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ TheIDE » U++ TheIDE: Compiling, Linking, Debugging of your packages » Suppressions file for valgrind
Suppressions file for valgrind [message #16163] Fri, 30 May 2008 06:04 Go to next message
Novo is currently offline  Novo
Messages: 1048
Registered: December 2006
Experienced Contributor
ubuntu.710.upp.valgrind.supp - file with suppressions prepared on Ubuntu 7.10 + X11 + GTK. Suppressions are checked on TheIDE.

I've added several suppressions for GTK.


Regards,
Novo

[Updated on: Sun, 01 June 2008 19:24]

Report message to a moderator

Re: Suppressions file for valgrind [message #16196 is a reply to message #16163] Sun, 01 June 2008 19:25 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1048
Registered: December 2006
Experienced Contributor
Updated file with suppressions.
I've added several suppressions for GTK.


Regards,
Novo
Re: Suppressions file for valgrind [message #16209 is a reply to message #16196] Mon, 02 June 2008 11:45 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1264
Registered: September 2007
Senior Contributor
Thanx! Updated in SVN 277 build.

Ciao

Max
Re: Suppressions file for valgrind [message #16224 is a reply to message #16209] Tue, 03 June 2008 05:44 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1048
Registered: December 2006
Experienced Contributor
mdelfede wrote on Mon, 02 June 2008 05:45

Thanx! Updated in SVN 277 build.

Ciao

Max



IMHO, there is no such thing as one universal suppression file. Each combination of different versions of X11 and GTK DLLs may have their own list of suppressions.

For some reason all issues in the current suppression file are related to fonts. That make me think that those are actually problems with U++ itself.


Regards,
Novo
Re: Suppressions file for valgrind [message #16256 is a reply to message #16224] Wed, 04 June 2008 12:15 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1264
Registered: September 2007
Senior Contributor
Novo wrote on Tue, 03 June 2008 05:44

mdelfede wrote on Mon, 02 June 2008 05:45

Thanx! Updated in SVN 277 build.

Ciao

Max



IMHO, there is no such thing as one universal suppression file. Each combination of different versions of X11 and GTK DLLs may have their own list of suppressions.



Well... you're right, I had to add some suppressions for different libraries on ubuntu 8.04. But, well, suppressing non-existent libraries does no harm Smile

Quote:


For some reason all issues in the current suppression file are related to fonts. That make me think that those are actually problems with U++ itself.


Well, I noticed it too, but there are issues even on some functions that just have XDisplay as parameter.... And I guess that those can't be related to UPP, as XDisplay is needed (and would not work with uninitialized one). So, it must be in X11, IMHO.

Max
Re: Suppressions file for valgrind [message #16260 is a reply to message #16256] Wed, 04 June 2008 18:59 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1048
Registered: December 2006
Experienced Contributor
mdelfede wrote on Wed, 04 June 2008 06:15


Well... you're right, I had to add some suppressions for different libraries on ubuntu 8.04. But, well, suppressing non-existent libraries does no harm Smile



Iím having an impression that suppressions slow down valgrind. Speed seems to depend on number of suppressions and length of stack trace in each suppression.

BTW, I've found an interesting message in valgrind mailing list:

One of the kinds of errors that Memcheck finds is dangerous uses
of uninitialised values, usually when they get used in an
if-statement.  This is a useful facility, but it is also the
single most complained about aspect of Memcheck.  The problem is
that the point where Memcheck reports the error is often a long
way after the heap or stack allocation that created the
uninitialised value.  And so it can be very difficult to find the
root cause of the problem.

Memcheck will now optionally track these origins, and, when
reporting an uninitialised value error, it can show the origin
too.  If the origin is a heap allocation, it shows where the
block was allocated.  If the origin was a stack allocation, it
will tell you the function that did the allocation.  A couple of
simple examples are shown below.

Of course there's no free lunch: Memcheck's speed is
approximately halved, and memory consumption increases by a
minimum of 100MB.  But in initial testing, on a large C++
codebase, it has proven effective.

You can try out this functionality using the SVN trunk:

  svn co svn://svn.valgrind.org/valgrind/trunk
  cd trunk
  ./autogen.sh
  ./configure --prefix=...

and then run with --track-origins=yes.

This functionality was inspired by the work of Bond, Nethercote,
et al, as reported in the paper "Tracking Bad Apples: Reporting
the Origin of Null and Undefined Value Errors"
(http://www.valgrind.org/docs/origin-tracking2007.pdf), but the
actual implementation is very different from that described in
the paper.

Feedback, comments, bug reports welcome.

J


Simple example of an uninitialised value use originating from
a heap block:

  Conditional jump or move depends on uninitialised value(s)
     at 0x400ACB: main (origin1-yes.c:64)
   Uninitialised value was created by a heap allocation
     at 0x4C234BB: malloc (vg_replace_malloc.c:207)
     by 0x400A9B: main (origin1-yes.c:61)

And one from a stack allocation (a local, or "auto" variable):

  Conditional jump or move depends on uninitialised value(s)
     at 0x400944: main (origin3-no.c:33)
   Uninitialised value was created by a stack allocation
     at 0x4008B4: main (origin3-no.c:15)

An example from the opposite end of the size/triviality spectrum:

  Use of uninitialised value of size 8
     at 0x4F277E7: BitmapReadAccess::SetPixelFor_24BIT_TC_BGR
                   (bmpacc2.cxx:195)
     by 0x4F1A8CE: Bitmap::ImplConvertUp (bmpacc.hxx:542)
     by 0x4F1B9D3: Bitmap::Convert (bitmap3.cxx:365)
   Uninitialised value was created by a heap allocation
     at 0x4C22DDB: malloc (vg_replace_malloc.c:207)
     by 0x719B4FA: rtl_allocateMemory (alloc_global.c:311)
     by 0x470BDA: allocate (operators_new_delete.cxx:160)
     by 0x470C4A: operator new[](unsigned long)
                  (operators_new_delete.cxx:239)
     by 0xEBCAABC: X11SalBitmap::ImplCreateDIB (salbmp.cxx:194)


Regards,
Novo
Re: Suppressions file for valgrind [message #16271 is a reply to message #16260] Thu, 05 June 2008 15:17 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1264
Registered: September 2007
Senior Contributor
Wow, tracing origin of un-initalized stuffs is a really big improvement ! Is it only on current svn tree ?

Max
Re: Suppressions file for valgrind [message #16275 is a reply to message #16271] Thu, 05 June 2008 17:07 Go to previous message
Novo is currently offline  Novo
Messages: 1048
Registered: December 2006
Experienced Contributor
mdelfede wrote on Thu, 05 June 2008 09:17

Wow, tracing origin of un-initalized stuffs is a really big improvement ! Is it only on current svn tree ?

Max



That was announced on Mach 04. Version 3.3.1 of Valgrind was released yesterday ...

Unfortunately, uninitialized value origin tracking is not mentioned in release notes. Probably it is not that important comparing to fixed bugs Wink


Regards,
Novo

[Updated on: Thu, 05 June 2008 17:09]

Report message to a moderator

Previous Topic: typeinfo error
Next Topic: Wierd: compiling crahes Window Manager!
Goto Forum:
  


Current Time: Sat Jul 04 05:08:40 CEST 2020

Total time taken to generate the page: 0.01154 seconds