bug-sed
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20490: [PATCH] fixup: reference to uninitialized variable with inval


From: Jim Meyering
Subject: bug#20490: [PATCH] fixup: reference to uninitialized variable with invalid sequence
Date: Wed, 6 May 2015 19:18:01 -0700

On Tue, May 5, 2015 at 4:58 PM, Norihiro Tanaka <address@hidden> wrote:
>
> On Sun, 3 May 2015 10:06:00 -0700
> Jim Meyering <address@hidden> wrote:
>
>> On Sat, May 2, 2015 at 7:09 PM, Jim Meyering <address@hidden> wrote:
>> > On Wed, Nov 5, 2014 at 7:36 AM, Norihiro Tanaka <address@hidden> wrote:
>> >> Uninitialized variable are referred with invalid sequence in
>> >> str_append_modified().
>> >>
>> >> When mbrtowc() returns (size_t) -1, wc is not changed, even if wc is
>> >> uninitialized.  below may return unexpected result in order that the
>> >> value is referred at a following position in source code.
>> >>
>> >>   $ echo a | LC_ALL=ja_JP.eucJP ./sed/sed -e 's/a/b\U\xb2c/'
>> >
>> > Thank you for the patch and reproducer.
>> > I've made some small improvements to the actual patch and
>> > wrote a valgrind-using test that I'm adding to the test suite.
>> > I've included your patch with an adjusted log, followed by
>> > the changes I made to it in a separate commit. That commit
>> > is separate solely to show what I've done; I will squash into your
>> > commit before I push, followed by the test-adding commit.
>>
>> I've updated the commit log to reference this just-closed issue,
>> with this line:
>>
>>   This addresses http://debbugs.gnu.org/20490
>>
>> Then pushed.
>
> I see that this bug itself is correctly fixed by the patch.
>
> I ran new test on CentOS 5.10 (x86), and ran accross an error in
> attachment even after applying the patch.

Thank you for the report and for testing.
That is seems to be due to a bug in that old version of valgrind:

  +valgrind: m_debuginfo/readdwarf.c:2262 (copy_convert_CfiExpr_tree):
Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.

that is not exposed when the require_valgrind_
shell function tests valgrind against "true".

We can easily accommodate that, so I wrote the attached patch.
Can you verify that it causes the test to be skipped on your
system?

Attachment: 0001-tests-skip-the-new-test-in-presence-of-buggy-valgrin.patch
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]