ESQL/C memory access error

Posted in 2007

Topics: Connectivity: ESQL/C, 4GL & Embedded SQL

Fernando Ortiz — 18 May 2007 09:00:46 -0700 — source: Usenet: comp.databases.informix

Hi, I tried to open a PMR with IBM about 'an error' valgrind detected accessing uninitialized memory, and they tell it's no error at all (neither a feature, thank god). Just is a way of coding with no side effects. Are they correct? Is it just a informational warning detected by valgrind? ERROR 'Use of uninitialised value of size 8' in function stcmpri (in /opt/ informix/lib/esql/libifos.so) PRODUCT VERSION $ esql -VIBM Informix CSDK Version 2.90, IBM Informix-ESQL Version 2.90.FC4R1 Software Serial Number RDS#N000000 OPERATING SYSTEM $ uname -a Linux vieja.fjcorona.com.mx 2.6.18-8.el5 #1 SMP Thu Mar 15 19:46:53 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux TEST CASE $ cat b.ec main () {EXEC SQL BEGIN DECLARE SECTION; date a_date; EXEC SQL END DECLARE SECTION; EXEC SQL WHENEVER ERROR STOP; EXEC SQL connect to 'stores7'; EXEC SQL select '' into :a_date from call_type where call_code = 'B'; } Compilation $ esql b.ec -o b DEBUG OUTPUT $ valgrind ./b ==12352== Memcheck, a memory error detector. ==12352== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.==12352== Using LibVEX rev 1658, a library for dynamic binary translation. ==12352== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==12352== Using valgrind-3.2.1, a dynamic binary instrumentation framework. ==12352== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==12352== For more details, rerun with: -v ==12352== ==12352== Use of uninitialised value of size 8 ==12352== at 0x5033787: stcmpri (in /opt/informix/lib/esql/ libifos.so) ==12352== by 0x4EEA097: todate (in /opt/informix/lib/esql/ libifgen.so) ==12352== by 0x4EE7E75: rvalcvar_flag (in /opt/informix/lib/esql/ libifgen.so) ==12352== by 0x4C5FC06: _sqvalhost (in /opt/informix/lib/esql/ libifsql.so) ==12352== by 0x4C4CFB3: _iqupdtargs (in /opt/informix/lib/esql/ libifsql.so) ==12352== by 0x4C5DF44: __slct (in /opt/informix/lib/esql/ libifsql.so) ==12352== by 0x4C5DC68: sqli_slct (in /opt/informix/lib/esql/ libifsql.so) ==12352== by 0x4007C7: main (in /opt/aubit/aubit4gltest/1305/b) ==12352== ==12352== Use of uninitialised value of size 8 ==12352== at 0x50337BB: stcmpri (in /opt/informix/lib/esql/ libifos.so) ==12352== by 0x4EEA097: todate (in /opt/informix/lib/esql/ libifgen.so) ==12352== by 0x4EE7E75: rvalcvar_flag (in /opt/informix/lib/esql/ libifgen.so) ==12352== by 0x4C5FC06: _sqvalhost (in /opt/informix/lib/esql/ libifsql.so) ==12352== by 0x4C4CFB3: _iqupdtargs (in /opt/informix/lib/esql/ libifsql.so) ==12352== by 0x4C5DF44: __slct (in /opt/informix/lib/esql/ libifsql.so) ==12352== by 0x4C5DC68: sqli_slct (in /opt/informix/lib/esql/ libifsql.so) ==12352== by 0x4007C7: main (in /opt/aubit/aubit4gltest/1305/b) ==12352== ==12352== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 1) ==12352== malloc/free: in use at exit: 129,785 bytes in 1,077 blocks. ==12352== malloc/free: 1,292 allocs, 215 frees, 267,607 bytes allocated. ==12352== For counts of detected errors, rerun with: -v ==12352== searching for pointers to 1,077 not-freed blocks. ==12352== checked 534,320 bytes. ==12352== ==12352== LEAK SUMMARY: ==12352== definitely lost: 0 bytes in 0 blocks. ==12352== possibly lost: 0 bytes in 0 blocks. ==12352== still reachable: 129,785 bytes in 1,077 blocks. ==12352== suppressed: 0 bytes in 0 blocks. ==12352== Reachable blocks (those to which a pointer was found) are not shown. ==12352== To see them, rerun with: --show-reachable=yes Thanks

↪ replying to Fernando Ortiz

Jonathan Leffler — Sat, 19 May 2007 18:55:05 GMT — source: Usenet: comp.databases.informix

Fernando Ortiz wrote: > Hi, > > I tried to open a PMR with IBM about 'an error' valgrind detected > accessing uninitialized memory, and they tell it's no error at all > (neither a feature, thank god). Just is a way of coding with no side > effects. > > Are they correct? Is it just a informational warning detected by > valgrind? > > ERROR > > 'Use of uninitialised value of size 8' in function stcmpri (in /opt/ > informix/lib/esql/libifos.so) > > PRODUCT VERSION > > $ esql -V> IBM Informix CSDK Version 2.90, IBM Informix-ESQL Version 2.90.FC4R1 > Software Serial Number RDS#N000000 > > OPERATING SYSTEM > > $ uname -a > Linux vieja.fjcorona.com.mx 2.6.18-8.el5 #1 SMP Thu Mar 15 19:46:53 > EDT 2007 x86_64 x86_64 x86_64 GNU/Linux> > TEST CASE > > $ cat b.ec > main () > {> EXEC SQL BEGIN DECLARE SECTION; > date a_date; > EXEC SQL END DECLARE SECTION; > > EXEC SQL WHENEVER ERROR STOP; > EXEC SQL connect to 'stores7'; > > EXEC SQL select '' into :a_date from call_type where call_code = 'B'; > } > > Compilation > > $ esql b.ec -o b> > DEBUG OUTPUT Judging from what I see, the code is poking at a value_t structure, and particularly the val->v_charp member of it, when it hasn't been properly initialized, probably because the '' is being interpreted as or treated as null, nearly. It is quite likely to be a bug. If I'm reading the code correctly, the stcmpri() is looking to see whether the string is equal to 'today' (case-insensitively). You could perhaps verify that by doing: EXEC SQL SELECT 'today' into :a_date FROM call_type WHERE call_code = 'B'; And observing whether you get the error report from valgrind (I'd expect not). You could also try an appropriate valid date string (eg '01/02/03' - though how the system will interpret that depends on your locale and environment); that would most likely avoid the error report too. It would be interesting to now what happens with ' ' instead of '', too. > $ valgrind ./b > ==12352== Memcheck, a memory error detector. > ==12352== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et > al.> ==12352== Using LibVEX rev 1658, a library for dynamic binary > translation. > ==12352== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. > ==12352== Using valgrind-3.2.1, a dynamic binary instrumentation > framework. > ==12352== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et > al. > ==12352== For more details, rerun with: -v > ==12352== > ==12352== Use of uninitialised value of size 8 > ==12352== at 0x5033787: stcmpri (in /opt/informix/lib/esql/ > libifos.so) > ==12352== by 0x4EEA097: todate (in /opt/informix/lib/esql/ > libifgen.so) > ==12352== by 0x4EE7E75: rvalcvar_flag (in /opt/informix/lib/esql/ > libifgen.so) > ==12352== by 0x4C5FC06: _sqvalhost (in /opt/informix/lib/esql/ > libifsql.so) > ==12352== by 0x4C4CFB3: _iqupdtargs (in /opt/informix/lib/esql/ > libifsql.so) > ==12352== by 0x4C5DF44: __slct (in /opt/informix/lib/esql/ > libifsql.so) > ==12352== by 0x4C5DC68: sqli_slct (in /opt/informix/lib/esql/ > libifsql.so) > ==12352== by 0x4007C7: main (in /opt/aubit/aubit4gltest/1305/b) > ==12352== > ==12352== Use of uninitialised value of size 8 > ==12352== at 0x50337BB: stcmpri (in /opt/informix/lib/esql/ > libifos.so) > ==12352== by 0x4EEA097: todate (in /opt/informix/lib/esql/ > libifgen.so) > ==12352== by 0x4EE7E75: rvalcvar_flag (in /opt/informix/lib/esql/ > libifgen.so) > ==12352== by 0x4C5FC06: _sqvalhost (in /opt/informix/lib/esql/ > libifsql.so) > ==12352== by 0x4C4CFB3: _iqupdtargs (in /opt/informix/lib/esql/ > libifsql.so) > ==12352== by 0x4C5DF44: __slct (in /opt/informix/lib/esql/ > libifsql.so) > ==12352== by 0x4C5DC68: sqli_slct (in /opt/informix/lib/esql/ > libifsql.so) > ==12352== by 0x4007C7: main (in /opt/aubit/aubit4gltest/1305/b) > ==12352== > ==12352== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from > 1) > ==12352== malloc/free: in use at exit: 129,785 bytes in 1,077 blocks. > ==12352== malloc/free: 1,292 allocs, 215 frees, 267,607 bytes > allocated. > ==12352== For counts of detected errors, rerun with: -v > ==12352== searching for pointers to 1,077 not-freed blocks. > ==12352== checked 534,320 bytes. > ==12352== > ==12352== LEAK SUMMARY: > ==12352== definitely lost: 0 bytes in 0 blocks. > ==12352== possibly lost: 0 bytes in 0 blocks. > ==12352== still reachable: 129,785 bytes in 1,077 blocks. > ==12352== suppressed: 0 bytes in 0 blocks. > ==12352== Reachable blocks (those to which a pointer was found) are > not shown. > ==12352== To see them, rerun with: --show-reachable=yes > > Thanks > -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2007.0226 -- http://dbi.perl.org/

↪ replying to Jonathan Leffler

Fernando Ortiz — 21 May 2007 05:39:20 -0700 — source: Usenet: comp.databases.informix

On May 19, 1:55 pm, Jonathan Leffler <jleff...@earthlink.net> wrote: > > Judging from what I see, the code is poking at a value_t structure, and > particularly the val->v_charp member of it, when it hasn't been properly > initialized, probably because the '' is being interpreted as or treated > as null, nearly. It is quite likely to be a bug. If I'm reading the > code correctly, the stcmpri() is looking to see whether the string is > equal to 'today' (case-insensitively). You could perhaps verify that by > doing: > > EXEC SQL SELECT 'today' into :a_date > FROM call_type WHERE call_code = 'B'; > Same error ==31047== Use of uninitialised value of size 8 ==31047== at 0x50337A3: stcmpri (in /opt/informix/lib/esql/ libifos.so) ==31047== by 0x4EEA097: todate (in /opt/informix/lib/esql/ libifgen.so) ==31047== by 0x4EE7E75: rvalcvar_flag (in /opt/informix/lib/esql/ libifgen.so) ==31047== by 0x4C5FC06: _sqvalhost (in /opt/informix/lib/esql/ libifsql.so) ==31047== by 0x4C4CFB3: _iqupdtargs (in /opt/informix/lib/esql/ libifsql.so) ==31047== by 0x4C5DF44: __slct (in /opt/informix/lib/esql/ libifsql.so) ==31047== by 0x4C5DC68: sqli_slct (in /opt/informix/lib/esql/ libifsql.so) ==31047== by 0x4007C7: main (in /root/b) ==31047== ==31047== Conditional jump or move depends on uninitialised value(s) ==31047== at 0x5033793: stcmpri (in /opt/informix/lib/esql/ libifos.so) ==31047== by 0x4EEA097: todate (in /opt/informix/lib/esql/ libifgen.so) ==31047== by 0x4EE7E75: rvalcvar_flag (in /opt/informix/lib/esql/ libifgen.so) ==31047== by 0x4C5FC06: _sqvalhost (in /opt/informix/lib/esql/ libifsql.so) ==31047== by 0x4C4CFB3: _iqupdtargs (in /opt/informix/lib/esql/ libifsql.so) ==31047== by 0x4C5DF44: __slct (in /opt/informix/lib/esql/ libifsql.so) ==31047== by 0x4C5DC68: sqli_slct (in /opt/informix/lib/esql/ libifsql.so) ==31047== by 0x4007C7: main (in /root/b) > And observing whether you get the error report from valgrind (I'd expect > not). But no error with today without the ' EXEC SQL select today into :a_date from call_type where call_code = 'B'; > You could also try an appropriate valid date string (eg > '01/02/03' - though how the system will interpret that depends on your > locale and environment); that would most likely avoid the error report No error with valid date ==31062== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1) ==31062== malloc/free: in use at exit: 129,762 bytes in 1,077 blocks. ==31062== malloc/free: 1,299 allocs, 222 frees, 269,172 bytes allocated. ==31062== For counts of detected errors, rerun with: -v ==31062== searching for pointers to 1,077 not-freed blocks. ==31062== checked 534,280 bytes. > too. It would be interesting to now what happens with ' ' instead of > '', too. > No error either with single space > > Thanks

ESQL/C memory access error

Glossary

Your privacy choices