[unixODBC-dev] SQLConfigDataSource

Tom Hughes thh at cyberscience.com
Tue Nov 22 19:30:01 GMT 2005


In message <20842177.1132685030730.JavaMail.root at elwamui-rustique.atl.sa.earthlink.net>
          Igor Korot <ikorot at earthlink.net> wrote:

> When I run Valgrind on my program, I got following:
> 
> ==348== Conditional jump or move depends on uninitialised value(s)
> ==348==    at 0x1B8F20AD: strlen (in /lib/ld-2.3.5.so)
> ==348==    by 0x1C35A154: (within /lib/libc-2.3.5.so)
> ==348==    by 0x1C35A26B: _dl_sym (in /lib/libc-2.3.5.so)
> ==348==    by 0x1C38BE20: (within /lib/libdl-2.3.5.so)
> ==348==    by 0x1B8EDC57: _dl_catch_error (in /lib/ld-2.3.5.so)
> ==348==    by 0x1C38C247: (within /lib/libdl-2.3.5.so)
> ==348==    by 0x1C38BE85: dlsym (in /lib/libdl-2.3.5.so)
> ==348==    by 0x1D01589F: sys_dl_sym (ltdl.c:1172)
> ==348==    by 0x1D01831E: lt_dlsym (ltdl.c:3966)
> ==348==    by 0x1D00E246: SQLConfigDataSource (SQLConfigDataSource.c:93)
> ==348==    by 0x1CFE704B: CODBCConfigure::OnCreateDSN(wxCommandEvent&) (odbcconfigure.cpp:112)
> ==348==    by 0x1C01BDEA: wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const (appbase.cpp:328)

That's probably valgrind failing to understand the highly optimised
strlen implementation in ld.so and not a real problem.

What version of valgrind is it anyway - we do try and intercept
those strlens and redirect them to a less optimised version to
avoid these problems.

Of course it always could be a real problem, either in unixODBC
or libltdl or glibc... Try adding a VALGRIND_CHECK_READABLE call
on the arguments to lt_dlsym in SQLConfigDataSource if you want
to rule our unixODBC problems.

Tom

-- 
Tom Hughes (thh at cyberscience.com)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/



More information about the unixODBC-dev mailing list