Valgrind tool which is a well known memory analyzing tool reports an Invalid Read in OCIStmtPrepare in Oracle C API Function. This can be observed in several such Oracle C API functions. Please refer the following stack trace. According to my observations and understanding the the application creates a buffer of 317 bytes. However when it is passed to Oracle library it does some memory copy using the __intel_new_memcpy function. However the __intel_new_memcpy function copies 320 bytes (which is 8 from 312). The actual allocated memory was 317 bytes. Could you please confirm whether this behaviour correct? What goes wrong in this? ==22195== Invalid read of size 8 ==22195== at 0x68CD2D9: __intel_new_memcpy (in /x02/app/oracle/product/11.2.0/client_1/lib/libclntsh.so.11.1) ==22195== by 0x5D84158: kpurclientparse (in /x02/app/oracle/product/11.2.0/client_1/lib/libclntsh.so.11.1) ==22195== by 0x5D878DE: kpureq (in /x02/app/oracle/product/11.2.0/client_1/lib/libclntsh.so.11.1) ==22195== by 0x5D607FA: OCIStmtPrepare (in /x02/app/oracle/product/11.2.0/client_1/lib/libclntsh.so.11.1) ==22195== by 0x4099E0: DBCursor::Parse(char const*) (OCICPP.C:1020) ==22195== by 0x40CE29: DBCon::NewCursor(char const*, int) (OCICPP.C:753) ==22195== by 0x4047A6: main (main.cpp:59) ==22195== Address 0xa2e7e68 is 312 bytes inside a block of size 317 alloc'd ==22195== at 0x4C26E1C: operator new[](unsigned long) (vg_replace_malloc.c:305) ==22195== by 0x4EBD00F: String::Set(char const*, unsigned int) (String.cpp:544) ==22195== by 0x4EBD169: String::Set(char const*) (String.cpp:512) ==22195== by 0x4EBD188: String::operator=(char const*) (String.cpp:590) ==22195== by 0x404784: main (main.cpp:55)
According to my understanding the valgrind does check it correctly. But the __intel_new_memcpy function does some optimization itself by reading the entire memory block once in 8 bytes. Can someone please clarify. I agree that this should be ask from intel rather than asking from valgrind. However the valgrind code has some functionalities releated to ICC. That is the actual reason for asking the issue from valgrind team. Hope this error should be already investigated by valgrind team.
What version of Valgrind are you using here? Can you re-run with the extra flag --partial-loads-ok=yes ?
Issue re-created in Valgrind-3.12 with --partial-loads-ok=yes ==29820== Invalid read of size 16 ==29820== at 0x7616268: __intel_sse2_strlen (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x6AC1737: nlstddt_do_alter_trace (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x87E6A0B: nlstdggo (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x87E624C: nlstdgg (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x6B58DD7: nigini2 (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x6FB6024: kpeDbgTLSInit (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x88A7BA9: kpummTLSGET1 (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x6FB5AE6: kpeDbgProcessInit (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x6FB3920: kpummpin (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x6A32B4F: kpuenvcr (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x76DB588: OCIEnvNlsCreate (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x4E4A0FD: soci::oracle_session_backend::oracle_session_backend(std::string const&, std::string const&, std::string const&, int, bool, int, int) (session.cpp:147) ==29820== by 0x4E498FB: soci::oracle_backend_factory::make_session(soci::connection_parameters const&) const (factory.cpp:188) ==29820== by 0x4E5ECF1: soci::session::open(soci::connection_parameters const&) (session.cpp:124) ==29820== by 0x4E5F5C0: soci::session::open(soci::backend_factory const&, std::string const&) (session.cpp:132) ==29820== by 0x4B3653: main (Main.cpp:198) ==29820== Address 0xf7f7300 is 16 bytes inside a block of size 17 alloc'd ==29820== at 0x4C2875E: malloc (vg_replace_malloc.c:296) ==29820== by 0x4C288DB: realloc (vg_replace_malloc.c:692) ==29820== by 0xC91AC56: ssMemRealloc (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntshcore.so.12.1) ==29820== by 0x8800318: nlattctl (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x6B58CC8: nigini2 (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x6FB6024: kpeDbgTLSInit (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x88A7BA9: kpummTLSGET1 (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x6FB5AE6: kpeDbgProcessInit (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x6FB3920: kpummpin (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x6A32B4F: kpuenvcr (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x76DB588: OCIEnvNlsCreate (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x4E4A0FD: soci::oracle_session_backend::oracle_session_backend(std::string const&, std::string const&, std::string const&, int, bool, int, int) (session.cpp:147) ==29820== by 0x4E498FB: soci::oracle_backend_factory::make_session(soci::connection_parameters const&) const (factory.cpp:188) ==29820== by 0x4E5ECF1: soci::session::open(soci::connection_parameters const&) (session.cpp:124) ==29820== by 0x4E5F5C0: soci::session::open(soci::backend_factory const&, std::string const&) (session.cpp:132) ==29820== by 0x4B3653: main (Main.cpp:198) ==29820== Invalid read of size 16 ==29820== at 0x761BF90: __intel_ssse3_rep_memcpy (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x7615F25: _intel_fast_memcpy.P (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x8821D71: ttcpip (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x880962E: ttcdrv (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x87F8728: nioqwa (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x87DA82B: upirtrc (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x87E5045: kpurcsc (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x6A4F66B: kpulfln (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x69F8897: OCILobGetLength (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x4E485E1: soci::oracle_blob_backend::get_len() (blob.cpp:46) ==29820== by 0x4B3653: main (Main.cpp:198) ==29820== Address 0x14391e80 is 4,192 bytes inside a block of size 4,200 alloc'd ==29820== at 0x4C2875E: malloc (vg_replace_malloc.c:296) ==29820== by 0xCA609A2: ssMemMalloc (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntshcore.so.12.1) ==29820== by 0x6C42369: sktsfMalloc (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x6FB48D1: kpummapg (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x8854BBF: kghgex (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x8853A48: kghfnd (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x8855F25: kghalo (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x88547FD: kghgex (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x8853A48: kghfnd (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x8855F25: kghalo (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x8503A9C: kpghhalo (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x6E3BA14: kollalfn (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x7D92926: kpccld2i (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x8817E6E: ttccfpg (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x8815869: ttcfour (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x880D423: ttcdrv (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x87F8728: nioqwa (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x87DA82B: upirtrc (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x87E5045: kpurcsc (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x87E26A4: kpufch0 (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x87E0D04: kpufch (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x87DB200: OCIStmtFetch (in /x01/app2/oracle/product/12.1.0.2/client_1/lib/libclntsh.so.12.1) ==29820== by 0x4E5075D: soci::oracle_statement_backend::fetch(int) (statement.cpp:102) ==29820== by 0x4E5752C: soci::details::statement_impl::fetch() (statement.cpp:420) ==29820== by 0x90FAA8: fetch (statement.h:181)
Oracle SR Logged and they said below. If you call malloc 317 bytes, it should actually allocate same number of bytes. Since our memory management routines are very complex and are internal Valgrind tool is not able to determine what goes on. You can safely ignore this warning, if you are not facing any error or memory leak. If any error or leak, please upload the test code so that i can reproduce the issue and file a new bug.
Issue logged in ICC page. https://software.intel.com/en-us/forums/intel-c-compiler/topic/698479 Still no proper answer. They just suggesting that "This memcpy function surely would take advantage of aligned memory, but should not require it. An aligned malloc would take additional bytes as required to get alignment, but a proper matching of malloc and free functions would free those extra unused bytes." And finally suggesting to check the assembly code.
No answer even in stack overflow. http://stackoverflow.com/questions/39845378/valgrind-reports-an-invalid-read-in-intel-new-memcpy
I see you are stuck among all different parties, everyone saying "our part behaves ok; it's not our fault". At this point I'd suggest you do as folks on Intel forum suggested, in combination with gdb+vgdb [1]. Use '--vgdb-error=1' or an appropriate number which will stop the execution right upon reaching the reported problem. Disassemble the offending part of __intel_new_memcpy(), observe values of relevant registers and report back here. [1] http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver