[UDUNITS #KOB-668895]: udunits2 issues

Sue,

> Here are three  problems I am seeing with use of udunits2:
> 
> PROBLEM1:
> 
> I use valgrind to detect memory leaks . Prior to adding udunits2 code I
> did not have any memory leaks or problems.  Following are issues I see
> for for ut_read_xml:
> 
> ==29932== Source and destination overlap in strncpy(0xBEDDBB76, 0xBEDDBB76, 
> 256)
> ==29932==    at 0x401EE64: strncpy (mc_replace_strmem.c:116)
> ==29932==    by 0x4207F9E: readXml (in 
> /home/dettling/Desktop/udunits-2.0.0/lib/libudunits2.so.0.0.0)
> ==29932==    by 0x420836E: ut_read_xml (in 
> /home/dettling/Desktop/udunits-2.0.0/lib/libudunits2.so.0.0.0)

I fixed the above by replacing the use of "strncpy" with "memmove".
I didn't know about "valgrind" on my new workstation.  I'll have to try it.

...
> PROBLEM2:
> 
> I get some funky overrides from udunits2.xml:
> 
> Definition of "kt" in "/opt/share/udunits2-common.xml", line 80, overrides 
> prefixed-unit "1000000 kilogram"
> Definition of "microns" in "/opt/share/udunits2-common.xml", line 290, 
> overrides prefixed-unit "1e-15 second"
> Definition of "ft" in "/opt/share/udunits2-common.xml", line 387, overrides 
> prefixed-unit "1e-12 kilogram"
> Definition of "yd" in "/opt/share/udunits2-common.xml", line 395, overrides 
> prefixed-unit "8.64e-20 second"
> Definition of "pt" in "/opt/share/udunits2-common.xml", line 616, overrides 
> prefixed-unit "1e-09 kilogram"
> Definition of "at" in "/opt/share/udunits2-common.xml", line 1013, overrides 
> prefixed-unit "1e-15 kilogram"
> Definition of "ph" in "/opt/share/udunits2-common.xml", line 1531, overrides 
> prefixed-unit "3.6e-09 second"
> Definition of "nt" in "/opt/share/udunits2-common.xml", line 1538, overrides 
> prefixed-unit "1e-06 kilogram"
> 
> These definitions of units and the prefixed unit dont seem to match. I am not
> sure if this is a problem.

It's not a problem; it's a feature!

Take, for example, "kt".  It could mean "kiloton" (1000000 kilograms).  The 
fact that the
XML database defines it to be a "knot" means that the prefixed interpretation 
is no
longer available and you're, consequently, informed of that fact.

You can disable the reporting of these overrides by calling
 "ut_set_error_message_handler(ut_ignore)".

> PROBLEM3:
> 
> I use ut_parse to create units and ut_free to free units and I have
> memory leaks. The program runs fine besides the leaks and other
> udunits2 issues.
> 
> //
> // Create a ut_unit from the units of the x coordinate variable.
> //
> ut_unit*  xUnit = ut_parse(unitSys,_inputGridX->getUnits(), UT_ASCII);
> 
> if (xUnit == NULL)
> {
> cerr << "ProjInfo::_initializeProj4(): ERROR: Cannot create a ut_unit "
> << "object from string " << _inputGridX->getUnits() << endl;
> 
> return 1;
> }
> 
> //
> // Create ut_units for "meter", "kilometer", "feet"
> //
> ut_unit*  mUnit =  ut_parse(unitSys,"meter", UT_ASCII);
> 
> if (mUnit == NULL)
> {
> cerr << "ProjInfo::_initializeProj4(): ERROR: Cannot create a ut_unit "
> << "object from string \'meter\'" << endl;
> 
> return 1;
> }
> 
> if( !ut_compare( xUnit, mUnit))
> { ... }
> 
> //
> // udunits2 cleanup
> //
> if (mUnit)
> ut_free(mUnit);
> 
> if (xUnit)
> ut_free(xUnit);
> 
> if(unitSys)
> ut_free_system(unitSys);
> 
> Some valgrind memory error output:
> 
> ==30075== 55,505,974 (137,680 direct, 55,368,294 indirect) bytes in 3,442 
> blocks are definitely lost in loss record 12 of 14
> ==30075==    at 0x401D38B: malloc (vg_replace_malloc.c:149)
> ==30075==    by 0x42055EC: yy_flex_alloc (in /opt/lib/libudunits2.so.0.0.0)
> ==30075==    by 0x4205822: ut_create_buffer (in /opt/lib/libudunits2.so.0.0.0)
> ==30075==    by 0x42058A8: utrestart (in /opt/lib/libudunits2.so.0.0.0)
> ==30075==    by 0x4207A27: ut_parse (in /opt/lib/libudunits2.so.0.0.0)
> ==30075==    by 0x42097DB: mapIdToUnit (in /opt/lib/libudunits2.so.0.0.0)
> ==30075==    by 0x42099C9: mapIdsToUnit (in /opt/lib/libudunits2.so.0.0.0)
> ==30075==    by 0x4209A91: mapNamesToUnit (in /opt/lib/libudunits2.so.0.0.0)
> ==30075==    by 0x420A20C: endElement (in /opt/lib/libudunits2.so.0.0.0)
> ==30075==    by 0x420FEF2: doContent (in /opt/lib/libudunits2.so.0.0.0)
> ==30075==    by 0x42107B9: contentProcessor (in /opt/lib/libudunits2.so.0.0.0)
> ==30075==    by 0x420AB6D: XML_ParseBuffer (in /opt/lib/libudunits2.so.0.0.0)
> ==30075==
> ==30075==
> ==30075== 1,032,398 bytes in 65 blocks are possibly lost in loss record 13 of 
> 14
> ==30075==    at 0x401D38B: malloc (vg_replace_malloc.c:149)
> ==30075==    by 0x42055EC: yy_flex_alloc (in /opt/lib/libudunits2.so.0.0.0)
> ==30075==    by 0x420583E: ut_create_buffer (in /opt/lib/libudunits2.so.0.0.0)
> ==30075==    by 0x42058A8: utrestart (in /opt/lib/libudunits2.so.0.0.0)
> ==30075==    by 0x4207A27: ut_parse (in /opt/lib/libudunits2.so.0.0.0)
> ==30075==    by 0x42097DB: mapIdToUnit (in /opt/lib/libudunits2.so.0.0.0)
> ==30075==    by 0x42099C9: mapIdsToUnit (in /opt/lib/libudunits2.so.0.0.0)
> ==30075==    by 0x4209A91: mapNamesToUnit (in /opt/lib/libudunits2.so.0.0.0)
> ==30075==    by 0x420A0BF: endElement (in /opt/lib/libudunits2.so.0.0.0)
> ==30075==    by 0x420FEF2: doContent (in /opt/lib/libudunits2.so.0.0.0)
> ==30075==    by 0x42107B9: contentProcessor (in /opt/lib/libudunits2.so.0.0.0)
> ==30075==    by 0x4210BD9: prologProcessor (in /opt/lib/libudunits2.so.0.0.0)

I'll have to investigate this and get back to you.

> Are there some obvious misuses of the udunits2 lib?
> 
> Thanks for your help.

Thanks for reporting!

> Sue

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: KOB-668895
Department: Support UDUNITS
Priority: Normal
Status: On Hold