Maciej Sieczka wrote: > I have just noticed that g.region -g or -p crashes in a latlon location. > Example:
> 0x00007f33d130f69e in sincos (val=0.90594848802138783, > sin_val=0x7fffda923030, > cos_val=0x7fffda923028) at GDapi.c:6265 > 6265 *sin_val = sin(val); > (gdb) bt > #0 0x00007f33d130f69e in sincos (val=0.90594848802138783, > sin_val=0x7fffda923030, cos_val=0x7fffda923028) at GDapi.c:6265 > #1 0x00007f33d130f6a3 in sincos (val=0.90594848802138783, > sin_val=0x7fffda923060, cos_val=0x7fffda923058) at GDapi.c:6265 > #2 0x00007f33d130f6a3 in sincos (val=0.90594848802138783, > sin_val=0x7fffda923090, cos_val=0x7fffda923088) at GDapi.c:6265 > (The whole backtrace is all very long.) When you say "very long", is it actually finite? Or did you give up before reaching the end? Because the line which the debugger shows: > 6265 *sin_val = sin(val); doesn't appear to be a recursive call, but the backtrace indicates an infinite "direct" recursion (i.e. the function calls itself with exactly the same arguments). My guess is that the saved frame pointer is actually pointing to the current frame, i.e. a linked list where "p->next == p". In any case, this doesn't help identify the real problem. Can you step through the g.region code from the beginning and find where in g.region (or the GRASS libraries) that it's going out of control? -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
