[GRASS-dev] release planning and no volume display on Mac - Any info on where crash happens?

Wed Jan 2 21:08:43 PST 2013

When I put in values between 15 and 20 I can see the horizontal outline of a rectangle but not the 3D shape of a box. No isosurfaces display. No crash either.

I un-commented line 684 and commented line 1009 in gvl_calc_c to see what happens to slices

 /* gvl_align_data(pos, slice->data); */

A horizontal slice displays and I can manipulate it in the X and Y direction. But I cannot manipulate it in the Z direction. Also, a Z dimension slice shows up only as a line. Also, isosurfaces do not display. But there is no crash for either isosurfaces or slices when I comment out this line. On the face of it, a memory issue related to display in the Z dimension is causing a crash. Commenting out calls to gvl_align_data in gvl_calc_c stops the crash and stops display in the Z dimension. There is also something called gvl_calc2_c in this folder. Its code is very similar to gvl_calc_c

I'm guessing that Martin and Helena know the most about the relevant C code for lib/ogsf/*. Glynn may have some insight into this too. Anyone else is welcome to chime in.

FWIW, the last time gvl_calc_c was touched was by Glynn 4 years ago (glynn: Fix char/char* mismatch (merge from trunk, r32757)).

Volume display worked as recently as fall 2011 AFAIK.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 	480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:          480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jan 2, 2013, at 10:21 AM, Helena Mitasova <hmitaso at ncsu.edu> wrote:

> 
> 
> On Jan 2, 2013, at 1:34 AM, Michael Barton wrote:
> 
>> Testing with GRASS 6.4.3RC2
>> 
>> Rem-ing out line 684 in gvl_calc_c
>> 
>> /* gvl_align_data(dbuff[i].ndx_new, dbuff[i].new); */
>> 
>> prevents crashing. But I don't see an isosurface.
>> 
>> 
>> 
>> Helena, 
>> 
>> I'm using your test data (jr_7408MR_2m_t70)
>> 
>> What is a good value to set for an isosurface to see anything?
> 
> anything between 15 to 20 should work.
> You can move the volume a little bit above the surface to see the entire isosurface
> Here is an example of settings that I have used (the name of the volume raster is slightly different
> but it is the same data).
> 
>> m.nviz.image elevation_map=JR_2008_ALL -a mode=fine resolution_fine=1 color=243:243:243 volume=JR_7408MR_2m volume_shading=gouraud volume_resolution=1 volume_position=0,0,20 isosurf_level=1:17.0 isosurf_color_map=JR_7408MR_2m isosurf_transp_value=0 position=0.11,0.07 height=243 perspective=13 twist=0 zexag=6.000000 focus=569,593,17 light_position=0.26,-0.30,0.61 light_brightness=94 light_ambient=55 light_color=255:255:255 output=nviz_output format=ppm size=798,545
> 
> This volume includes no-data because the original rasters were masked, I think it would be useful to start with a volume without no-data - 
> just use r3.null to replace no-data with 0.
> 
> Let me know if it would be useful for me to run same thing in MacOSX 10.6 (I still don't have 10.8 machine quite ready),
> (see the slides 12 and 13 here for the isosurfaces at different levels, I have the isosurfaces colored by year - I don't think I gave you 
> that raster, so your isosurfaces should be just a single color).
> http://skagit.meas.ncsu.edu/~helena/publwork/AGU2012lidar6.pptx
> 
> Helena
> 
>> Slices still crash because they still call gvl_align_data. As before, though initially displaying a slice works fine. It only crashes when I try to change something about the slice and it wants to redraw.
>> 
>> Michael
>> ____________________
>> C. Michael Barton
>> Director, Center for Social Dynamics & Complexity 
>> Professor of Anthropology, School of Human Evolution & Social Change
>> Arizona State University
>> 
>> voice: 	480-965-6262 (SHESC), 480-727-9746 (CSDC)
>> fax:          480-965-7671 (SHESC),  480-727-0709 (CSDC)
>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Jan 1, 2013, at 1:24 PM, Anna Kratochvílová <kratochanna at gmail.com>
>> wrote:
>> 
>>> Hi Michael,
>>> 
>>> On Tue, Jan 1, 2013 at 8:48 PM, Michael Barton <Michael.Barton at asu.edu> wrote:
>>>> Hi Anna,
>>>> 
>>>> On the slim chance that you are online today, can you tell me where gvl_align_data in gvl_calc.c reside in either the source code or compiled code? I have a bit of down time and thought I'd see what I could find out about the volume display breaking. I don't know C but can selectively rem out some things and see what happens.
>>> 
>>> It should be here
>>> http://trac.osgeo.org/grass/browser/grass/trunk/lib/ogsf/gvl_calc.c#L685
>>> 
>>> Also, you could try debugging with QtCreator [1] (as an user-friendly
>>> interface to the debugger), it is quite easy, here [2] is some help
>>> for setting up the project. I don't know what method you would like to
>>> use but this is the easiest I know. I suppose it should work on Mac,
>>> too.
>>> 
>>> Regards,
>>> Anna
>>> 
>>> [1] http://qt-project.org/downloads
>>> [2] http://grasswiki.osgeo.org/wiki/Using_QtCreator_for_GRASS_C_development#Debugging
>>> 
>>> 
>>>> 
>>>> 
>>>> Thanks
>>>> Michael
>>>> ____________________
>>>> C. Michael Barton
>>>> Director, Center for Social Dynamics & Complexity
>>>> Professor of Anthropology, School of Human Evolution & Social Change
>>>> Arizona State University
>>>> 
>>>> voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
>>>> fax:          480-965-7671 (SHESC),  480-727-0709 (CSDC)
>>>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Dec 6, 2012, at 12:07 AM, Anna Kratochvílová <kratochanna at gmail.com> wrote:
>>>> 
>>>>> Hi Michael,
>>>>> 
>>>>> On Wed, Dec 5, 2012 at 11:02 PM, Michael Barton <michael.barton at asu.edu> wrote:
>>>>>> Any suggestions yet on where the crash I documented in
>>>>>> http://trac.osgeo.org/grass/ticket/1736 actually happens in the code so that
>>>>>> I can take a look at it and see if there is something fixable for the Mac? I
>>>>>> posted what I hope is the relevant debug output to help identify this.
>>>>>> 
>>>>>> While we may need to think about wxPython 2.9, it seems best to first look
>>>>>> at what line is actually causing the crash and see if there is a fix or
>>>>>> workaround.
>>>>> 
>>>>> The crash occurs probably in gvl_align_data in gvl_calc.c. The error
>>>>> message 'pointer being realloc'd was not allocated' is quite clear,
>>>>> however it's not clear why it happens on Mac only. Maybe someone with
>>>>> better knowledge of C could understand it more.
>>>>> 
>>>>> Anna
>>>>> 
>>>>>> 
>>>>>> Michael
>>>>>> ____________________
>>>>>> C. Michael Barton
>>>>>> Director, Center for Social Dynamics & Complexity
>>>>>> Professor of Anthropology, School of Human Evolution & Social Change
>>>>>> Arizona State University
>>>>>> 
>>>>>> voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
>>>>>> fax:          480-965-7671 (SHESC),  480-727-0709 (CSDC)
>>>>>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>> 
> 