|
Bugzilla – Full Text Bug Listing |
| Summary: | lilypond is miscompiled | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Michal Marek <mmarek> |
| Component: | Development | Assignee: | GCC Development Team at SuSE <development-gcc> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | sbrabec |
| Version: | Beta 3 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
Will look into it. gcc.gnu.org/PR26258 Thanks! Adding lilypond maintainer to cc. This should now be fixed on STABLE. |
The package lilypond is (probably) miscompiled on STABLE: $ lilypond /usr/share/doc/packages/lilypond/input/wilhelmus.ly GNU LilyPond 2.6.5 Processing `/usr/share/doc/packages/lilypond/input/wilhelmus.ly' Parsing... Interpreting music... [8][16][24] Preprocessing graphical objects... Segmentation fault (core dumped) The problem is in file lilypond-2.6.5/lily/music-sequence.cc, in function music_list_to_relative (SCM, Pitch, bool). The local variable 'last' isn't completely initialised when the for-loop doesn't pass any cycle (valgrind warns about uninitialised value). If you compile this function with -O0, the segfault disappears. This is what I got from "-g --save-temps" (comments mine): music-sequence.cc: ... 91 Pitch 92 music_list_to_relative (SCM l, Pitch p, bool ret_first) 93 { 94 Pitch first = p; // default copy-constructor for class Pitch 95 int count = 0; 96 // last.octave_ will contain garbage sometimes, 97 Pitch last = p; // which causes trouble later 98 for (SCM s = l; scm_is_pair (s); s = scm_cdr (s)) 99 { 100 if (Music *m = unsmob_music (scm_car (s))) 101 { 102 last = m->to_relative_octave (last); 103 if (!count++) 104 first = last; 105 } 106 } 107 108 return (ret_first) ? first : last; 109 } ... music-sequence.s: ... .globl _Z22music_list_to_relativeP17scm_unused_struct5Pitchb .type _Z22music_list_to_relativeP17scm_unused_struct5Pitchb, @function _Z22music_list_to_relativeP17scm_unused_struct5Pitchb: .LFB864: .loc 1 92 0 .LVL45: pushq %r13 .LCFI27: movl %ecx, %r13d pushq %r12 .LCFI28: pushq %rbp .LCFI29: .LBB250: .LBB251: .loc 1 98 0 movq %rdi, %rbp .LBE251: .LBE250: .loc 1 92 0 pushq %rbx .LCFI30: subq $120, %rsp .LCFI31: .LVL46: .LBB252: .LBB253: .loc 1 98 0 testb $6, %dil .LBE253: .LBE252: .loc 1 92 0 movq %rsi, 16(%rsp) movl 16(%rsp), %eax movl %edx, 24(%rsp) movl 20(%rsp), %ecx .LVL47: .LBB254: .LBB255: .loc 1 94 0 movl %eax, 48(%rsp) .loc 1 97 0 movl %eax, 32(%rsp) .loc 1 98 0 jne .L81 movq (%rdi), %rax movq %rdi, %rbx testb $1, %al jne .L81 ; jump over the for-loop (?) .loc 1 97 0 ; finish initialisation of 'last' (?) xorl %r12d, %r12d .LVL48: movl %edx, 40(%rsp) movl %ecx, 36(%rsp) jmp .L84 .p2align 4,,7 ... This is where I got with my trial-and-error debugging. Maybe it's some obscure bug in the program, I'm sorry in that case...