[GRASS-dev] r.watershed failing: seg fault and exit code 35584

[Markus Metz]

Tested with a 144 million cells DEM and threshold=10, r.watershed
completes successfully here. Can you try to debug with gdb or
valgrind? See [1] for some info on GRASS debugging.

Markus M

[1] http://grass.osgeo.org/wiki/GRASS_Debugging


Markus Metz wrote:
> Chris Carleton wrote:
>>
>> As for the r.watershed problem, it's occurring
>> again and I'm now using GRASS 6.4 RC6 with 64bit support.
>
> Apparently you are comfortable to build from source. No need to use
> outdated RC6, use the latest weekly snapshot instead, available at [1]
>
>>
>> Here are the region settings I'm using;
>> zone:       16
>> datum:      wgs84
>> ellipsoid:  wgs84
>> north:      1942292.77488498
>> south:      1798172.56898554
>> west:       174812.49733566
>> east:       382055.4579663
>> nsres:      15.00002143
>> ewres:      15.00021429
>> rows:       9608
>> cols:       13816
>> cells:      132744128
>>
>> And here is the output in the terminal from strace and r.watershed;
>>
>> GRASS 6.4.0RC6 (ccarleton.minanha.utm):~/ > strace r.watershed
>> elevation=aster_srtm_dem_filled at CloudRemoval threshold=100
>> stream=aster_srtm_streams
>>
>> ...
>>
>> SECTION 1b (of 5): Determining Offmap Flow.
>>  100%
>> SECTION 2: A * Search.
>>  100%
>> SECTION 3: Accumulating Surface Flow.
>>  100%
>> SECTION 4: Watershed determination.
>> Segmentation fault
>
> I will test it myself next week, currently on the road.
>
> Markus M
>
> [1] http://grass.osgeo.org/grass64/source/snapshot/
>
>
>>
>> I've attached the whole strace stdout to this email. Again, I'm using Ubuntu
>> 10.04 LTS 64bit. Does anyone have any ideas about where to start
>> troubleshooting this? Thanks,
>>
>> Chris
>>
>>
>> On 24 August 2010 09:55, Chris Carleton <w.ccarleton at gmail.com> wrote:
>>>
>>> Okay thanks. I was using a 'trial-and-error' method for determining the
>>> threshold, but I think I ought to start large and proceed toward smaller
>>> values. I haven't come across any analytical method for determining the best
>>> threshold value for stream extraction. Some smart person needs to develop a
>>> statistically sound method for assessing the uncertainty associated with
>>> geophysical feature extraction so that multiple results can be compared
>>> meaningfully and we're not left to assess the validity of a result on the
>>> basis of whether or not it 'looks okay' and preferably that doesn't involve
>>> going into the field to count streams. I'm going to compile GRASS from
>>> source with the latest stable release and configure for 64bit support. I
>>> think the current install was done through the repository so it's behind and
>>> not optimized. On that note, I'm trying to figure out what the appropriate
>>> configure flag(s) is(are) for HDF4 and HDF5 support in GDAL so that I can
>>> open HDF files in GRASS. The only like that I can find that seems to be
>>> discussing it formally is here:
>>>
>>> http://trac.osgeo.org/gdal/wiki/HDF
>>>
>>> Does anyone have the answer handy or another link with instructions that
>>> are more clear? Thanks,
>>>
>>> Chris
>>>
>>> On 24 August 2010 05:39, Markus Metz <markus.metz.giswork at googlemail.com>
>>> wrote:
>>>>
>>>> Martin Landa:
>>>> >
>>>> > Chris Carleton:
>>>> >> I haven't been able to find something in the mailing lists about this,
>>>> >> but
>>>> >> if you know of somewhere that I can find a solution I'd appreciate the
>>>> >> link.
>>>> >> I'm running GRASS 6.4 RC5 on Ubuntu LTS 10.04 with a Dell Precision
>>>> >> T7500
>>>> >> Workstation. The region settings are as follows;
>>>> >
>>>> > RC5 is quite old - please try RC6 or better fresh SVN.
>>>> >
>>>> The Ubuntu version and grass version used are both true 64bit?
>>>> Processing over 130 million cells with r.watershed in memory and 12GB
>>>> is possible, but only if grass is compiled as a 64bit application.
>>>>
>>>> SECTION 4: Watershed determination is pretty much unchanged since RC5,
>>>> the segfault might also happen in current 6.4.
>>>>
>>>> The combination of threshold=10 and over 130 million cells is a bit
>>>> unusual, producing a very large number of stream segments, but AFAICT
>>>> not large enough to trigger a segfault.
>>>>
>>>> Markus M
>>>>
>>>
>>
>>
>