Re: Conversion functions.

[David Nečas (Yeti) <yeti physics muni cz>]

On Tue, Sep 04, 2007 at 04:18:23PM +0200, Magnus Myrefors wrote:
> I tested my code with valgrind and I got some error-messages
> that derived from my own code.I changed the code and then
> the error-messages disapperad. I still get wrong values that 
> seem to occur randomly though... 
>   Below is the output from valgrind. It is the end of the
> error-messages that were generated when the program is reading 
> the text-file and use g_ascii_strtod().

Errors like

> ==3782== Conditional jump or move depends on uninitialised value(s)
> ==3782==    at 0x467A1F6: g_unichar_isspace (guniprop.c:275)
> ==3782==    by 0x446C1BE: pango_default_break
> (in /usr/lib/libpango-1.0.so.0.1400.8)
> ==3782==    by 0x446D2B0: pango_break
> (in /usr/lib/libpango-1.0.so.0.1400.8)
> ==3782==    by 0x447D7E2: (within /usr/lib/libpango-1.0.so.0.1400.8)
> ==3782==    by 0x447E26A: (within /usr/lib/libpango-1.0.so.0.1400.8)
> ==3782==    by 0x447F282: pango_layout_get_pixel_extents
> (in /usr/lib/libpango-1.0.so.0.1400.8)
> ==3782==    by 0x40AB99E: get_size (gtkcellrenderertext.c:1522)
> ==3782==    by 0x40A6053: gtk_cell_renderer_get_size
> (gtkcellrenderer.c:536)
> ==3782==    by 0x4246DA6: gtk_tree_view_column_cell_get_size
> (gtktreeviewcolumn.c:2606)
> ==3782==    by 0x422E52D: validate_row (gtktreeview.c:4693)
> ==3782==    by 0x4232388: do_validate_rows (gtktreeview.c:5255)
> ==3782==    by 0x4239F8B: gtk_tree_view_size_request
> (gtktreeview.c:1822)

are printed long after the data is loaded I suppose.  They
can mean crap stored in the tree model, or perhaps they are
harmless (normally I do not see treeviews produce these).

In any case they do not say anything about the conversion
problem (they say the test program is probably not very
minimal though).  If no *different* errors are printed
first, then we have not found anything.

Simple things that can be tried next:
- if the numbers are normal, i.e. supported by underlying
  strtod(), try to use it directly -- be careful with the
  locale in this case
- copy g_ascii_strtod() from the latest glib/strfuncs.c,
  paste to your code and use this copy to see whether it
  makes any difference

Still, the randomness indicates a nasty bug in your program.
I suppose if you make a minimal program that just reads the
data, the problem goes away.

Yeti

--
http://gwyddion.net/