Created attachment 136941 [details]
Patch

I originally reported this problem in the thread at https://sourceforge.net/p/valgrind/mailman/valgrind-developers/thread/20190909131626.9633-1-mac%40mcrowe.com/#msg36759152 but I don't think it reached a conclusion. Some of what follows is based on information provided in that thread by Mark Wielaard.

STEPS TO REPRODUCE

Compile:
---8<---
#include <iconv.h>
#include <stdio.h>

int main()
{
    iconv_t descriptor = iconv_open("UCS-4BE", "euc-kr");
    if (descriptor == (iconv_t)(-1)) {
        fprintf(stderr, "Failed to get iconv\n");
        return 1;
    }

    fprintf(stderr, "Got iconv\n");

    return 0;
}
---8<---

and run with:

 valgrind --default-suppressions=no ./a.out

(For at least valgrind 3.16.1 and valgrind 3.17.0.)

Expected result:

 No complaints from valgrind.

Actual result:

==344358== Memcheck, a memory error detector                                                          
==344358== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==344358== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==344358== Command: ./a.out                                                                           
==344358==                                                                                            
==344358== Invalid read of size 8                                                                     
==344358==    at 0x401D54C: strncmp (strcmp.S:173)                                                    
==344358==    by 0x400604D: is_dst (dl-load.c:209)                                                    
==344358==    by 0x4008566: _dl_dst_count (dl-load.c:246)                
==344358==    by 0x4008757: expand_dynamic_string_token (dl-load.c:388)
==344358==    by 0x40088D1: fillin_rpath.isra.0 (dl-load.c:460)
==344358==    by 0x4008BE1: decompose_rpath (dl-load.c:631)              
==344358==    by 0x4009745: cache_rpath (dl-load.c:673)
==344358==    by 0x4009745: cache_rpath (dl-load.c:654)                                               
==344358==    by 0x4009745: _dl_map_object (dl-load.c:2074)                                           
==344358==    by 0x400DD90: openaux (dl-deps.c:64)                                                    
==344358==    by 0x499925F: _dl_catch_exception (dl-error-skeleton.c:208)
==344358==    by 0x400E108: _dl_map_object_deps (dl-deps.c:248)
==344358==    by 0x4013D7A: dl_open_worker (dl-open.c:571) 
==344358==    by 0x499925F: _dl_catch_exception (dl-error-skeleton.c:208)
==344358==  Address 0x4a29981 is 1 bytes inside a block of size 8 alloc'd
==344358==    at 0x483979B: malloc (vg_replace_malloc.c:380)
==344358==    by 0x401C0BA: strdup (strdup.c:42)  
==344358==    by 0x4008B74: decompose_rpath (dl-load.c:606)              
==344358==    by 0x4009745: cache_rpath (dl-load.c:673)        
==344358==    by 0x4009745: cache_rpath (dl-load.c:654)                   
==344358==    by 0x4009745: _dl_map_object (dl-load.c:2074)              
==344358==    by 0x400DD90: openaux (dl-deps.c:64)                                                    
==344358==    by 0x499925F: _dl_catch_exception (dl-error-skeleton.c:208)
==344358==    by 0x400E108: _dl_map_object_deps (dl-deps.c:248)
==344358==    by 0x4013D7A: dl_open_worker (dl-open.c:571)
==344358==    by 0x499925F: _dl_catch_exception (dl-error-skeleton.c:208)
==344358==    by 0x40138C9: _dl_open (dl-open.c:837)   
==344358==    by 0x49986DC: do_dlopen (dl-libc.c:96)                   
==344358==    by 0x499925F: _dl_catch_exception (dl-error-skeleton.c:208)

(and two more similar complaints in strncmp.)

(Note that the current Debian Testing valgrind v3.16.1 emits the errors even without "--default-suppressions=no".)

The attached patch fixes this problem for me by using valgrind's implementation of strncmp instead. In the previously mentioned email thread I claimed to have seen this when compiling for sufficiently modern x86 too, but I have not reproduced this recently.