[GRASSLIST:28] Re: Bus Error in g.remove

[Dave Kent]

Hi:

I ran the program.  It listed every file and directory in the  
system.  I aborted it after a few minutes before it finished.  There  
were no error messages.

Note that I have reinstalled older GRASS version that works and the  
system is not the same as when the problem occurred.

Hope this is helpful.

Dave


On Mar 9, 2006, at 9:48 PM, Huidae Cho wrote:

> I've made those changes in mid-February this year.  Could you try  
> running the
> following code and let me know what this does?  Don't worry, it's  
> like "find
> dir" command.
>
> cc -o list list.c -Wall
> ./list /
>
> ---<list.c>---
> #include <stdio.h>
> #include <string.h>
> #include <unistd.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <dirent.h>
>
> static int recursive_list(const char *path);
>
> int
> main(int argc, char *argv[])
> {
> 	if(argv[1])
> 		return recursive_list(argv[1]);
> 	return 1;
> }
>
> static int
> recursive_list(const char *path)
> {
>         DIR *dirp;
>         struct dirent *dp;
>         struct stat sb;
>         char path2[1024];
>
>         if(lstat(path, &sb))
>                 return 1;
>         if(!S_ISDIR(sb.st_mode))
> 	{
> 		printf("file: %s\n", path);
> 		return 0;
> 	}
>
>         if((dirp = opendir(path)) == NULL)
>                 return 1;
>         while((dp = readdir(dirp)) != NULL)
>         {
>                 if(dp->d_name[0] == '.')
>                         continue;
>                 sprintf(path2, "%s/%s", path, dp->d_name);
>                 recursive_list(path2);
>         }
>         closedir(dirp);
>
> 	printf(" dir: %s/\n", path);
>         return 0;
> }
> --------------
>
> On Thu, Mar 09, 2006 at 08:33:26PM +1300, Hamish wrote:
>> Just a thought,
>>
>> in the past weeks some code was changed to replace system calls with
>> their C equivalents. Maybe this has something to do with it. I can't
>> connect to the CVS-web interface currently to check.
>>
>> Look for recent changes in:
>>   http://freegis.org/cgi-bin/viewcvs.cgi/grass6/general/manage/
>>
>>
>> Hamish
>>
>>
>>
>> On Wed, 08 Mar 2006 21:04:54 -0600
>> Dave Kent <dkent at sasktel.net> wrote:
>>
>>> Thanks for the insight.  I went back to the Nov 05 binaries and
>>> Janurary CVS version and things work.  That will be fine for now.  I
>>> guess learning how to build wouldn't  be a bad thing.
>>>
>>> Thanks for your help.
>>>
>>> Dave
>>>
>>> On Mar 8, 2006, at 6:40 PM, William Kyngesburye wrote:
>>>
>>>> This is probably the same bug Michael Barton reported yesterday
>>>> (#4152) and I reported last August (#3585).  Specifically, when
>>>> GRASS is built on OS 10.3 Panther (GCC 3.3), and GDAL has Postgres
>>>> support.  It's probably happening for you in Tiger because Lorenzo
>>>> builds with Panther compatibility - either on Panther, or on Tiger
>>>> using the Panther SDK.  A Tiger-only build (GCC 4) is unaffected.
>>>>
>>>> It's a strange bug - I can build GRASS with GDAL without Postgres
>>>> support, then update GDAL to include Postgres support and it still
>>>> works.  It's only when GDAL has Postgres support *at the time GRASS
>>>>
>>>> is built*.  I've tried various combinations of static and dynamic
>>>> Postgres libraries (and the exact same ones used for Postgres
>>>> support in GRASS) and other options in GDAL and GRASS and GRASS
>>>> with/without its own Postgres support.
>>>>
>>>> On Mar 8, 2006, at 6:14 PM, Dave Kent wrote:
>>>>
>>>>> I am using Grass 6.1CVS on Macintosh with the most recent
>>>>> Macintosh binaries.
>>>>>
>>>>> g.remove gives the following error.
>>>>>
>>>>> child killed: bus error
>>>>> child killed: bus error
>>>>>     while executing
>>>>> "exec -- $cmd --tcltk"
>>>>>     (procedure "execute" line 4)
>>>>>     invoked from within
>>>>> "execute g.remove "
>>>>>     (menu invoke)
>>>>>
>>>>> This started quite suddenly, possibly consistent with messing with
>>>>
>>>>> AWK post I had yesterday.
>>>>>
>>>>> I get the same error with g.copy, g.rename but not g.list
>>>>>
>>>>> I have reinstalled the binaries and the application.
>>>>>
>>>>> There was a not too similar message in the archives which relates
>>>>> to the environmental variable file being corrupted.  I cannot find
>>>>> this file and haven't tried removing it.
>>