[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.