www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: GC don't understand

reply Nahon <lburger hu.tesco-europe.com> writes:
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
Nov 16 2006
next sibling parent reply Mariano <rotoshi yahoo.com> writes:
== 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.
Nov 16 2006
next sibling parent Laszlo Burger <nahon t-online.hu> writes:
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.
Nov 16 2006
prev sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
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
Nov 16 2006
prev sibling parent reply BCS <BCS pathlink.com> writes:
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

Nov 16 2006
parent Nahon <nahon t-online.hu> writes:
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).
Nov 16 2006