ESQL/C memory access error

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
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2007.0226 -- http://dbi.perl.org/

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
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2007.0226 -- http://dbi.perl.org/

On May 19, 1:55 pm, Jonathan Leffler 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

On May 19, 1:55 pm, Jonathan Leffler 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