bug reports for valgrind warnings?

2011-08-24 Thread Reinhold Kainhofer
I let valgrind run lilypond (both with optimization turned on and off) on all 
our regtests, and some of them (3-4) showed some warnings like invalid read 
access or uninitialized values. 

Shall I open a bug report for each regtest where valgrind shows a warning (the 
guile GC warnings are of course filtered out using a suppressions file)?

Some might really point to bugs (like the uninitialized variables that I fixed 
yesterday) or even to heisenbugs (which are not possible to track down, the 
more you narrow the area of the bug, the less you can reproduce it - you know, 
Heisenberg's uncertainty principle).

Cheers,
Reinhold
-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: bug reports for valgrind warnings?

2011-08-24 Thread Graham Percival
On Wed, Aug 24, 2011 at 02:08:41PM +0200, Reinhold Kainhofer wrote:
 Shall I open a bug report for each regtest where valgrind shows a warning 
 (the 
 guile GC warnings are of course filtered out using a suppressions file)?

I wouldn't be surprised if you get some duplicate bugs, though --
I mean, if there was one line in the slur code that produced a
memory error, I'd expect it to show up in dozens of regtests.
I definitely want to see all valgrind-reported bugs fixed (or at
least, explained why it's a false positive), but I'm not certain
that reporting bugs for every regtest is the best way.

Instead, could you post your suppression file and command-line (or
add it to the CG?), so that other people can easily see those
errors?  Then maybe we can have a few people each working on
different regtests.  :)

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: bug reports for valgrind warnings?

2011-08-24 Thread Reinhold Kainhofer
Am Mittwoch, 24. August 2011, 18:18:33 schrieben Sie:
 On Wed, Aug 24, 2011 at 02:08:41PM +0200, Reinhold Kainhofer wrote:
  Shall I open a bug report for each regtest where valgrind shows a warning
  (the guile GC warnings are of course filtered out using a suppressions
  file)?
 
 I wouldn't be surprised if you get some duplicate bugs, though --
 I mean, if there was one line in the slur code that produced a
 memory error, I'd expect it to show up in dozens of regtests.

You'd be surprised: With the --disable-optimising configure option, there are 
basically just two relevant warnings!

One in grid-lines.ly and one in laissez-vibrer-tie-beam.ly. I'm attaching my 
suppressions file and the output of valgrind.

I have the following alias in my ~/.bashrc (or rather in ~/.aliases, which I 
source from .bashrc):
alias valgrind-ly='valgrind --trace-children=yes --
suppressions=/home/reinhold/lilypond/guile_supp --track-origins=yes --num-
callers=25 lilypond '

Then call valgrind in input/regression/ as:
valgrind-ly grid-lines.ly laissez-vibrer-tie-beam.ly



There is, however, one caveat with the suppressions: Some uninitialized 
variables might be handled to guile (e.g. scm_from_int) and they will only 
show up as uninitialized variables in the garbage collection handling.

The (suppressed) output would then look something like:
»mozart-hrn-3.ly« wird verarbeitet
[...]
==14418== Use of uninitialised value of size 4
==14418==at 0x827C877: Stencil::mark_smob(scm_unused_struct*) 
(stencil.cc:54)
==14418==by 0x409F48B: scm_gc_mark (in /usr/lib/libguile.so.17.3.1)
==14418==by 0x409F639: scm_mark_locations (in /usr/lib/libguile.so.17.3.1)
==14418==by 0x40F6001: scm_threads_mark_stacks (in 
/usr/lib/libguile.so.17.3.1)
[...]
Text_interface::interpret_string(scm_unused_struct*, scm_unused_struct*, 
scm_unused_struct*) (text-interface.cc:64)
==14418==by 0x8290045: 
Text_interface::interpret_markup(scm_unused_struct*, scm_unused_struct*, 
scm_unused_struct*) (text-interface.cc:95)
[...]
==14418==  Uninitialised value was created by a stack allocation
==14418==at 0x828FA36: 
Text_interface::interpret_string(scm_unused_struct*, scm_unused_struct*, 
scm_unused_struct*) (text-interface.cc:58)

I don't see whether in this case where are some uninitialized values in the 
lilypond code, though.


Such a case were the uninitialized variables that I fixed yesterday, which 
were immediately passed to scm_from_int and triggered the warning only in the 
GC. Unfortunately, most warnings in the GC are really from guile.



An optimized build basically gives basically the same warnings.

Cheers,
Reinhold

-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org
{
   guile1
   Memcheck:Cond
   ...
   fun:scm_i_gc
}

{
   guile2
   Memcheck:Value4
   ...
   fun:scm_i_gc
}

{
   guile3
   Memcheck:Cond
   ...
   fun:scm_gc_mark
}

{
   guile4
   Memcheck:Value4
   ...
   fun:scm_gc_mark
}

{
   guile5
   Memcheck:Cond
   fun:scm_i_sweep_card
}

==28412== Memcheck, a memory error detector
==28412== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==28412== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==28412== Command: /home/reinhold/.bin/lilypond grid-lines.ly 
laissez-vibrer-tie-beam.ly
==28412== 
==28412== Memcheck, a memory error detector
==28412== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==28412== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==28412== Command: /home/reinhold/lilypond/lilypond/out/bin/lilypond --relocate 
grid-lines.ly laissez-vibrer-tie-beam.ly
==28412== 
GNU LilyPond 2.15.9
»grid-lines.ly« wird verarbeitet
Analysieren...
Interpretation der Musik...
Vorverarbeitung der grafischen Elemente...==28412== Invalid read of size 4
==28412==at 0x8074823: 
Axis_group_interface::adjacent_pure_heights(scm_unused_struct*) 
(axis-group-interface.cc:254)
==28412==by 0x4090F18: scm_dapply (in /usr/lib/libguile.so.17.3.1)
==28412==by 0x4097807: scm_apply (in /usr/lib/libguile.so.17.3.1)
==28412==by 0x4099160: scm_call_1 (in /usr/lib/libguile.so.17.3.1)
==28412==by 0x812748A: Grob::try_callback_on_alist(scm_unused_struct**, 
scm_unused_struct*, scm_unused_struct*) (grob-property.cc:227)
==28412==by 0x81271D6: Grob::internal_get_property(scm_unused_struct*) 
const (grob-property.cc:184)
==28412==by 0x8073D5A: 
Axis_group_interface::part_of_line_pure_height(Grob*, bool, int, int) 
(axis-group-interface.cc:147)
==28412==by 0x8073F23: 
Axis_group_interface::begin_of_line_pure_height(Grob*, int) 
(axis-group-interface.cc:171)
==28412==by 0x8073B6F: 
Axis_group_interface::sum_partial_pure_heights(Grob*, int, int) 
(axis-group-interface.cc:130)