Opened 5 years ago

Closed 5 years ago

Last modified 3 years ago

#2357 closed defect (fixed)

r3.info segfaults or reports incorrect values on Windows

Reported by: annakrat Owned by: grass-dev@…
Priority: normal Milestone: 7.2.0
Component: Raster3D Version: svn-releasebranch70
Keywords: r3.info Cc:
CPU: Unspecified Platform: MSWindows 8

Description

When I run r3.info on Windows on a map computed with v.vol.rst, it's segfaults and stops writing output after:

 |        Projection: Lambert Conformal Conic (zone 0)
 |            N:        100    S:          0   Res:     1
 |            E:        100    W:          0   Res:     1

When I create a random map:

g.region w=0 e=100 s=0 n=100 t=100 b=0 res=1 res3=1
r3.mapcalc "test = rand(0,100)"

it doesn't segfault but I get nonsense (I guess it's the same problem):

|        Projection: Lambert Conformal Conic (zone 0)
|            N:        100    S:          0   Res:     1
|            E:        100    W:          0   Res:     1
|            T:          0    B:          0   Res:     0
|   Range of data:   min =          0 max =          0

The same map copied to linux has no problems. Perhaps the function format_double could cause it since it is used for reporting top, bottom and range values.

Further investigation shows that r.info reports wrong number of categories (0) on a map which has categories. This would again point at format_double function which looks completely the same as in r3.info. However, v.info seems to work although it uses again format_double function, but slightly modified:

r(3).info:

void format_double(const double value, char *buf)
{
    sprintf(buf, "%.8lf", value);
    G_trim_decimal(buf);
}

v.info:

void format_double(double value, char *buf)
{
    sprintf(buf, "%.8f", value);
    G_trim_decimal(buf);
}

Could the l in the formatting make difference on Windows?

Change History (4)

comment:1 Changed 5 years ago by wenzeslaus

I seems that some C standards allow l to precede f but they also say that lf is the same as f. From this it seems that on MS Windows, because of MinGW or whatever, lf have unpredictable behavior. So, since it is not different form f (both mean double), I suggest to replace all occurrences of lf by f.

Also, the fact that there is more than format_double() function tells me that it should be moved to the library. It might also avoid possibility of bugs like this. The function looks pretty general, or at least, it is used generally. Or do you think that these small functions should not go to the library?

comment:2 Changed 5 years ago by annakrat

I removed the l from the function in r3.info module to test if it makes difference (r61172).

comment:3 in reply to:  2 Changed 5 years ago by annakrat

Resolution: fixed
Status: newclosed

Replying to annakrat:

I removed the l from the function in r3.info module to test if it makes difference (r61172).

This fixed the problem. I applied it to r.info (r61189) and backported to releasebranch (r61190) .

comment:4 Changed 3 years ago by neteler

Milestone: 7.1.07.2.0

Milestone renamed

Note: See TracTickets for help on using tickets.