Thanks, Chris, I looked at the two kde bugs you pointed out. Neither of them was an "invalid write". Also the software is actually failing here - not "working but getting valgrind errors" as was the case with the kde bugs.
In my case I have "failing and getting valgrind errors". I can run the same case on an older version of perl and an older version of "DBD::Oracle" module (with the exact same oracle database) and get no errors. Valgrind documentation describes an "invalid write" as follows: http://valgrind.org/docs/manual/mc-manual.html#mc-manual.badrw For example: Invalid read of size 4 at 0x40F6BBCC: (within /usr/lib/libpng.so.2.1.0.9) by 0x40F6B804: (within /usr/lib/libpng.so.2.1.0.9) by 0x40B07FF4: read_png_image(QImageIO *) (kernel/qpngio.cpp:326) by 0x40AC751B: QImageIO::read() (kernel/qimage.cpp:3621) Address 0xBFFFF0E0 is not stack'd, malloc'd or free'd This happens when your program reads or writes memory at a place which Memcheck reckons it shouldn't. In this example, the program did a 4-byte read at address 0xBFFFF0E0, somewhere within the system-supplied library libpng.so.2.1.0.9, which was called from somewhere else in the same library, called from line 326 of qpngio.cpp, and so on. Memcheck tries to establish what the illegal address might relate to, since that's often useful. So, if it points into a block of memory which has already been freed, you'll be informed of this, and also where the block was freed. Likewise, if it should turn out to be just off the end of a heap block, a common result of off-by-one-errors in array subscripting, you'll be informed of this fact, and also where the block was allocated. If you use the --read-var-info option Memcheck will run more slowly but may give a more detailed description of any illegal address. In this example, Memcheck can't identify the address. Actually the address is on the stack, but, for some reason, this is not a valid stack address -- it is below the stack pointer and that isn't allowed. In this particular case it's probably caused by GCC generating invalid code, a known bug in some ancient versions of GCC. Note that Memcheck only tells you that your program is about to access memory at an illegal address. It can't stop the access from happening. So, if your program makes an access which normally would result in a segmentation fault, you program will still suffer the same fate -- but you will get a message from Memcheck immediately prior to this. In this particular example, reading junk on the stack is non-fatal, and the program stays alive. -----Original Message----- From: Christopher Jones [mailto:christopher.jo...@oracle.com] Sent: Monday, January 15, 2018 6:56 PM To: dbi-users@perl.org Subject: Re: Hunting down (possible) memory leak in DBD::Oracle On 16/1/18 9:17 am, Fennell, Brian wrote: > $ egrep -B1 -A20 -i 'invalid write' > /copy/sandbox/feeds/data/search4_1/valgrind-log.txt | head -22 > ==19402== ==19402== Invalid write of size 4 > ==19402== at 0xBD747E6: __intel_ssse3_rep_memcpy (in > /db/app/oracle/product/12.1.0/client_1/lib/libclntsh.so.12.1) > ==19402== by 0xBD6CE95: _intel_fast_memcpy.P (in > /db/app/oracle/product/12.1.0/client_1/lib/libclntsh.so.12.1) Valgrind doesn't do the greatest on binaries built with the Intel compiler: https://bugs.kde.org/show_bug.cgi?id=286769 https://bugs.kde.org/show_bug.cgi?id=139776 Chris -- http://twitter.com/ghrd
