[GRASSLIST:9514] Re: aaargh! another location lost

[Ian MacMillan]

Lorenzo and others, I have tried to re-create this scenario several  
times, but can't repeat it (only the two times I have written about).   
I can't tell you if it would happen without using the aqua interface,  
but each time it did happen while I was using that interface (I am not  
sure if it could have anything to do with it or not).

The file names of the locations were rather simple:
worldmerc
latlong_wgs84

the mapset names were just:
ianmacmillan

I tried to find these locations on my system, but they haven't been  
moved.  I have looked for individual files within the mapsets, and  
can't find those either.

I am currently running a virus scan on my computer, but I doubt that is  
it as the only data loss I have ever experienced are these two  
locations, and they were both the target locations of the imagery  
groups that I was working on while the loss happened.

Thanks all for your thoughts (keep em coming), I will keep trying to  
figure things out on my end as well.

-Ian

On Dec 15, 2005, at 8:51 AM, Lorenzo Moretti wrote:

> Hi Ian
>
>> Hi all, so I hate to write about this again, but somehow I have had  
>> another location erased while using imagery commands.  This is the  
>> second time this has happened to me.  I have a hard time narrowing  
>> down how it happened this time, but last time I was using i.points,  
>> and a location disappeared (~300 MB of data) (GRASSLIST 8827).  This  
>> time I couldn't pin down which imagery command did it (I can only pin  
>> it down to a 5 minute time frame), but I again encountered problems  
>> using i.points.  I tried to run the program, but got a 'false start'  
>> where after entering the imagery group in the pop-up terminal window,  
>> the terminal window disappeared, and i.points never started up.   
>> Within minutes after this, I noticed that the target location had  
>> been erased (another ~500 MB down the drain).  Again, checking my  
>> bash_history, there is nothing there that would indicate a command  
>> that would do this.  I have also checked my whole computer for this  
>> location (or any files in it), to no avail.
>>
>> I am running 6.1cvs (Dec-12 Lorenzo's binaries) on mac 10.3.9.
>>
>> I can't understand what can be happening.  I have tried repeating my  
>> steps exactly, and can not get the same error in the program to  
>> occur.  I have no idea how to isolate the issue at all.  I have had  
>> no other troubles with this computer in 1.5 years of use, it has  
>> plenty of memory, and runs really smooth (like most macs).
>>
>> This is really strange behavior obviously, but very troublesome to me  
>> since it has happened twice now, though with slightly different  
>> causes.
>>
>> I have no idea how to test for this behavior, and looking at the  
>> responses from last time, I am not sure how they could necessarily  
>> result in this behavior multiple times.  Any other ideas out there?
>>
>> -Ian
>>
>> PS I know I need to back up data, and I do, but this is still  
>> infuriating.
>>
>
> This is a tragedy.
>
> For a test.
>
> Test under X11 only (menu and xterm) and under X11 and Aqua menu  
> (menu).
>
> Duplicate another location and re-try the i.points.
>
> Try and send me the result.
>
> and you wrote
>
>> Has anyone found out why malloc errors are appearing using v.in.ascii  
>> with Lorenzo's binaries?  I can't import any ascii files using 6.1cvs  
>> anymore, I have to revert back to 6.0.  The exact same commands that  
>> produce an error like:
>>
>> *** malloc[9282]: Deallocation of a pointer not malloced: 0x501740;  
>> This could be a double free(), or free() called with the middle of an  
>> allocated block; Try setting environment variable MallocHelp to see  
>> tools to help debug
>> *** malloc[9282]: Deallocation of a pointer not malloced: 0x501740;  
>> This could be a double free(), or free() called with the middle of an  
>> allocated block; Try setting environment variable MallocHelp to see  
>> tools to help debug
>> *** malloc[9282]: Deallocation of a pointer not malloced: 0x501740;  
>> This could be a double free(), or free() called with the middle of an  
>> allocated block; Try setting environment variable MallocHelp to see  
>> tools to help debug
>> *** malloc[9282]: error for object 0x501740: Incorrect checksum for  
>> freed object - object was probably modified after being freed; break  
>> at szone_error
>> Segmentation fault
>>
>> work using 6.0.  I have run into this problem intermittently since  
>> early October, and have seen it mentioned a few other times on this  
>> list since then.
>>
>> Any ideas?
>>
>> Thanks for your time,
>> Ian
>
> Send me your specific ascii file (tell me the coordinates) because I  
> want to test with other libraries. I don't know if it is a library  
> problem.
>
> Bye
>
> --  
> _______________________________________________________________________ 
> ___
> ||      Lorenzo Moretti        e-mail: lorenzo.moretti at bologna.enea.it  
>     ||/|/|  ENEA prot/idr          Web: http://wwwamb.bologna.enea.it/  
>    ||   |  via Don Fiammelli, 2   FTP: ftp://ftpamb.bologna.enea.it/  
> (ris.)
> ~~~~~~  40128 BOLOGNA - ITALY  Ph: +39-0516098086  Fax: +39-0516098131
> ENEA - Ente Nazionale per le Nuove Tecnologie, l'Energia e l'Ambiente
> ENEA - The Italian Agency for New Technologies, Energy and the  
> Environment
> _______________________________________________________________________ 
> ___
>
 >
 >
What happens if a big asteroid hits Earth? Judging from realistic  
simulations involving a sledge hammer and a common laboratory frog, we  
can assume it will be pretty bad.
  - Dave Barry


-------------------------------------------------------------
This message has been scanned by Postini anti-virus software.