Daniel Keep wrote:
>Access Violations can be caused by a few things.  One of these is attempting to use a null object, but it doesn't sound like that.  The other is attempting to use an object that's been deleted.
>
>D's GC should never delete an object you still have a reference to; are you deleting objects manually?  If so, that could be your problem: you're deleting an object and then trying to use it again.
>
>It's really the only thing I can think of at the moment; sorry.

Bill Baxter wrote:
>Could also be because you're passing D char[]'s to C functions that expect char*.  Any time you call a C function that takes a string, you need to call toStringz() on it.

Neither. Without GC (first line in main() is gc.disable(); ) it works as I
expect -- just consuming huge amount of memory (increasing every time a file
is accessed by the size of the file and a few bytes), physical and virtual
alike. I've tried a few things: I set the variable containing the file to "",
specified the length of it to 0, deleted it, but no use. I think I really need
the GC, but anyhow I use it (calling only xxxCollect() or minimize()) I get an
Access Violation. For me it would be an option to pause all other threads and
wait for a garbage collection phase then resume, but I found no way for it.
The other: as I mentioned I use threads. I couldn't figure out how but the
application doesn't destroy all finished threads. I collect them in an array
(type ownThread[int]) and if one is terminated then I remove the reference
from this array. Then I print out Thread.getAll().length and it is increasing
I don't know why. Is there any tool for removing those? (AFAIK when the
thread's run() finishes, the thread is terminated. Am I wrong?)

Regards,
Nahon

== Quote from Nahon (lburger@hu.tesco-europe.com)'s article
> Daniel Keep wrote:
> (AFAIK when the
> thread's run() finishes, the thread is terminated. Am I wrong?)
> Regards,
> Nahon

er, if you have an array with referecens to the threads, then they will be kept by the GC. You need to efectivelly
remove it from the array.
You can do this with ''threads.remove(dead)'' if in an associative array, or you have to do threads =
threads[1..dead]~threads[dead+1~length].

Mariano.

Mariano wrote:
> == Quote from Nahon (lburger@hu.tesco-europe.com)'s article
>> Daniel Keep wrote:
>> (AFAIK when the
>> thread's run() finishes, the thread is terminated. Am I wrong?)
>> Regards,
>> Nahon
> 
> er, if you have an array with referecens to the threads, then they will be kept by the GC. You need to efectivelly
> remove it from the array.
> You can do this with ''threads.remove(dead)'' if in an associative array, or you have to do threads =
> threads[1..dead]~threads[dead+1~length].
> 
> Mariano.

I did remove them, this is why I'm surprised.

One other thing that can cause GC errors is if you are keeping pointers someplace the GC can't look. This includes in C functions, data and what not, placing pointers in strings, files, casting tricks with ints (maybe), that XOR trick for pointer compressing in doublely liked lists. basically anything that will put a pointer someplace that doesn't look like a pointer.


placing wrote:
> Daniel Keep wrote:
> 
>>Access Violations can be caused by a few things.  One of these is
>>attempting to use a null object, but it doesn't sound like that.  The
>>other is attempting to use an object that's been deleted.
>>
>>D's GC should never delete an object you still have a reference to; are
>>you deleting objects manually?  If so, that could be your problem:
>>you're deleting an object and then trying to use it again.
>>
>>It's really the only thing I can think of at the moment; sorry.
> 
> 
> Bill Baxter wrote:
> 
>>Could also be because you're passing D char[]'s to C functions that
>>expect char*.  Any time you call a C function that takes a string, you
>>need to call toStringz() on it.
> 
> 
> Neither. Without GC (first line in main() is gc.disable(); ) it works as I
> expect -- just consuming huge amount of memory (increasing every time a file
> is accessed by the size of the file and a few bytes), physical and virtual
> alike. I've tried a few things: I set the variable containing the file to "",
> specified the length of it to 0, deleted it, but no use. I think I really need
> the GC, but anyhow I use it (calling only xxxCollect() or minimize()) I get an
> Access Violation. For me it would be an option to pause all other threads and
> wait for a garbage collection phase then resume, but I found no way for it.
> The other: as I mentioned I use threads. I couldn't figure out how but the
> application doesn't destroy all finished threads. I collect them in an array
> (type ownThread[int]) and if one is terminated then I remove the reference
> from this array. Then I print out Thread.getAll().length and it is increasing
> I don't know why. Is there any tool for removing those? (AFAIK when the
> thread's run() finishes, the thread is terminated. Am I wrong?)
> 
> Regards,
> Nahon

BCS wrote:
> One other thing that can cause GC errors is if you are keeping pointers someplace the GC can't look. This includes in C functions, data and what not, placing pointers in strings, files, casting tricks with ints (maybe), that XOR trick for pointer compressing in doublely liked lists. basically anything that will put a pointer someplace that doesn't look like a pointer.

In my short-life C experience I learned to avoid pointers. :) (Maybe that experience was too short-term.) And I'm very confused because all I use are objects (one instance and multiple ones in arrays), structs, strings and integral types. I do not manipulate the memory in any way beyond builtin D features. No external functions, no pointers, no XOR tricks or else. Nothing more than I used to, except the whole GC thing and the threads (I used fork long ago but that's completely different in aproach - mainly I have to use Windows). I would be all right without the GC (since the app works without it) if I could free the resources that D allocated in memory.
And I would feel very comforable with GC if I could trace these errors some way (for example with more explained error messages).

Mariano wrote:
> == Quote from Nahon (lburger@hu.tesco-europe.com)'s article
> 
>>Daniel Keep wrote:
>>(AFAIK when the
>>thread's run() finishes, the thread is terminated. Am I wrong?)
>>Regards,
>>Nahon
> 
> 
> er, if you have an array with referecens to the threads, then they will be kept by the GC. You need to efectivelly
> remove it from the array.
> You can do this with ''threads.remove(dead)'' if in an associative array, or you have to do threads =
> threads[1..dead]~threads[dead+1~length].
> 
> Mariano.

<shameless-plug>

Or:
# import cashew .utils .array ;
#
# // ...
# threads.drop(dead);

Which will perform better than the [..]~[..] expression.
Plus it reads funny: drop dead, thread!  ;)

</shameless-plug>

-- Chris Nicholson-Sauls