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

Michael Barton Michael.Barton at asu.edu
Sun Feb 3 10:13:47 PST 2013 

Markus and others,

I just tested this with GRASS trunk r54874 and it is still broken. 

Removing all reference to lines gvl_align_data (and the function as well) works. AFAICT, this only is called for viewing volumes. Does removing this function break volume viewing for any other platform?

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 Feb 3, 2013, at 5:16 AM, Markus Metz <markus.metz.giswork at gmail.com>
 wrote:

> I have not commented out both gvl_align_data lines (#684 and #1009) in
> gvl_calc.c, but fixed variable initialization in trunk r54866. Please
> test.
> 
> Markus M
> 
> On Fri, Jan 11, 2013 at 10:33 PM, Michael Barton <Michael.Barton at asu.edu> wrote:
>> Perhaps Windows and Linux--and earlier versions of OS X--ignore the code.
>> 
>> The header for gvl_calc.c says that the author is Tomas Paudits (February 2004). Does anyone know if he is still around to ask?
>> 
>> Michael
>> ______________________________
>> C. Michael Barton
>> Director, Center for Social Dynamics & Complexity
>> Professor of Anthropology, School of Human Evolution & Social Change
>> Arizona State University
>> Tempe, AZ  85287-2402
>> USA
>> 
>> voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
>> fax:          480-965-7671(SHESC), 480-727-0709 (CSDC)
>> www:    http://csdc.asu.edu, http://shesc.asu.edu
>>                http://www.public.asu.edu/~cmbarton
>> 
>> On Jan 11, 2013, at 1:18 PM, Helena Mitasova <hmitaso at ncsu.edu>
>> wrote:
>> 
>>> 
>>> On Jan 11, 2013, at 2:48 PM, Anna Kratochvílová wrote:
>>> 
>>>> Hi Michael,
>>>> 
>>>> On Mon, Jan 7, 2013 at 7:57 AM, Michael Barton <Michael.Barton at asu.edu> wrote:
>>>>> So I found a change that would make volumes visible again a week ago. Anyone have any thoughts about this? Do we need the function/procedure that sets the memory pointer for volume displays? Or can we simply get rid of it? Is it needed for Linux? Windows? Any thoughts about what happens without it?
>>>> 
>>>> I can confirm that removing those two lines does no harm for me
>>>> (Linux). However it's clear that we cannot just leave them out without
>>>> understanding why they are there. Can anyone (for example Glynn) think
>>>> of a reason why this code is crashing on Mac and not on Linux (no idea
>>>> about Windows)?
>>> 
>>> I just tested it on Windows 7 with WinGRASS6.4.3RC2 and I am happy to report that it works OK
>>> - both isosurfaces and crossections.
>>> 
>>> However, in the same WinGRASS6.4.3.RC2 there is a problem with the path to cellheader in G3d_read_window,
>>> so r3.info and g.region rast3d=myvoxel gives an error that the region is invalid.
>>> 
>>> Also, I finally got a laptop with MacOSX10.8 and I can confirm that in GRASS6.4.3RC2 binary
>>> posted Michael isusrfaces crash wxGUI. I will try to compile myself but I expect the result
>>> to be the same given that it crashed for William as well.
>>> 
>>> Helena
>>> 
>>>> And why removing of realloc helps?
>>>> 
>>>> Regards,
>>>> Anna
>>>> 
>>>>> 
>>>>> Cheers
>>>>> 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 11:22 PM, Michael Barton <michael.barton at asu.edu> wrote:
>>>>> 
>>>>>> GREAT NEWS!
>>>>>> 
>>>>>> Commenting out both gvl_align_data lines (#684 and #1009) in gvl_calc_c makes this work. Both slices and isosurfaces display and do not crash. I don't know if there would be a problem with larger files or not. But this is finally functional again.
>>>>>> 
>>>>>> BUT the command you sent does NOT work. It gives a segmentation fault error:
>>>>>> 
>>>>>> m.nviz.image elevation_map=JR_2008_ALL_dem at test3d -a mode=fine resolution_fine=6 color_map=JR_2008_ALL_dem at test3d volume=jr_7408MR_2m_t70 at test3d volume_shading=gouraud volume_resolution=1 volume_position=0,0,20 isosurf_level=1:18.0 isosurf_color_map=jr_7408MR_2m_t70 at test3d isosurf_transparency_value=0 slice=1:x,1:z slice_position=0.000000,1.000000,0.520000,1.000000,0.000000,1.000000,0.250000,0.720000,0.080000,1.000000,0.000000,1.000000 slice_transparency=0,0 position=0.84,0.16 height=356 perspective=20 twist=0 zexag=5.000000 focus=569,593,28 light_position=0.68,0.68,0.80 light_brightness=80 light_ambient=20 light_color=255:255:255 output=jrvoltest format=tif size=798,545
>>>>>> Loading raster map <JR_2008_ALL_dem at test3d>...
>>>>>> 100%
>>>>>> Loading raster map <JR_2008_ALL_dem at test3d>...
>>>>>> 100%
>>>>>> Translating colors from raster map <JR_2008_ALL_dem at test3d>...
>>>>>> 100%
>>>>>> Loading 3d raster map <jr_7408MR_2m_t70 at test3d>...
>>>>>> Segmentation fault: 11
>>>>>> 
>>>>>> 
>>>>>> Also, somewhere there is a bug somewhere that is sending progress bar text to the screen for any nviz activity (GRASS_INFO_PERCENT: 0...)
>>>>>> 
>>>>>> So now we have some kind of workaround. I don't know if there are any other down sides to bypassing this memory reallocation, but this is a good start on fixing this finally. Thanks Anna and Helena.
>>>>>> 
>>>>>> 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:45 PM, Helena Mitasova <hmitaso at ncsu.edu>
>>>>>> wrote:
>>>>>> 
>>>>>>> Michael,
>>>>>>> 
>>>>>>> what you describe sounds as if you had only one depth layer so let us check first that the 3D region is right.
>>>>>>> If the 3d region is set to the provided 3d raster given here
>>>>>>> http://skagit.meas.ncsu.edu/~helena/grasswork/JR_7408MR_2m_t70.asci
>>>>>>> http://skagit.meas.ncsu.edu/~helena/grasswork/JR_2008_ALL.asci (reference 2d raster)
>>>>>>> it should look like this
>>>>>>> 
>>>>>>> GRASS 6.4.3svn (nc_spm_05):~ > g.region -p3
>>>>>>> projection: 99 (Lambert Conformal Conic)
>>>>>>> zone:       0
>>>>>>> datum:      nad83
>>>>>>> ellipsoid:  a=6378137 es=0.006694380022900787
>>>>>>> north:      250690
>>>>>>> south:      249502
>>>>>>> west:       912791
>>>>>>> east:       913931
>>>>>>> top:        64.00000000
>>>>>>> bottom:     0.00000000
>>>>>>> nsres:      2
>>>>>>> nsres3:     2
>>>>>>> ewres:      2
>>>>>>> ewres3:     2
>>>>>>> tbres:      8
>>>>>>> rows:       594
>>>>>>> rows3:      594
>>>>>>> cols:       570
>>>>>>> cols3:      570
>>>>>>> depths:     8
>>>>>>> 
>>>>>>> can you then try to run the following command (please adjust the names of the 2d and 3d rasters to your actual names)
>>>>>>> 
>>>>>>> m.nviz.image elevation_map=JR_2008_ALL at Baseline_JR -a mode=fine resolution_fine=6 color_map=JR_2008_ALL at Baseline_JR \
>>>>>>> volume=JR_7408MR_2m_t70 at Baseline_JR volume_shading=gouraud volume_resolution=1 volume_position=0,0,20 isosurf_level=1:18.0 isosurf_color_map=JR_7408MR_2m_t70 at Baseline_JR isosurf_transparency_value=0 slice=1:x,1:z slice_position=0.000000,1.000000,0.520000,1.000000,0.000000,1.000000,0.250000,0.720000,0.080000,1.000000,0.000000,1.000000 slice_transparency=0,0 position=0.84,0.16 height=356 perspective=20 twist=0 zexag=5.000000 focus=569,593,28 \
>>>>>>> light_position=0.68,0.68,0.80 light_brightness=80 light_ambient=20 light_color=255:255:255 \
>>>>>>> output=jrvoltest format=tif size=798,545
>>>>>>> 
>>>>>>> it should generate an image with isosurfaces and a tilted crossection - it is not quite what I have on the screen, because
>>>>>>> it apparently uses some default values instead of actual values (e.g. for toggle normal direction and crossection) but it should have some
>>>>>>> isosurfaces. Let us know whether the command line works and we can go from there.
>>>>>>> 
>>>>>>> Helena
>>>>>>> 
>>>>>>> On Jan 3, 2013, at 12:08 AM, Michael Barton wrote:
>>>>>>> 
>>>>>>>> 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
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>> 
>> 
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev

More information about the grass-dev mailing list