Object reference weirdness
I have an array of objects that I've created and I'm abstracting arrays of these objects as a class of its own right. While testing my code I've run into some weird snags. I would get bus errors when calling a print() function, which is supposed to just print to the screen the values of the object's members. I've been trying to track this down and then ran into a situation where I am instantiating a brand new object and changing it's member values (without adding it to the array). Whenever I change it's values, a certain object in my array changes with it--it's reference is identical to the new one I just created. This is like a warp in spacetime somewhere. My object is some quantum object that has a twin and is being changed instantaneously but at a distance. Schrodinger's cat is rolling over in its grave. (kidding). What is happening here? Is this a garbage collection issue? I will send my code (and instructions on running it) to anyone who wants to take a look, but I'm afraid of subjecting the entire list to my spaghetti... ;-) -mike -- http://semiotech.org http://semiotech.org/michael
mike;
What is happening here? Is this a garbage collection issue?
I think ChucK has about as many garbage collection issues as I have problems understanding my grand-children... Could definitely be something that has to do with memory, there are some issues there; just this morning I think I allocated too much memory too quickly (say 3/4th of a gig in parallel shreds) and the results weren't pretty; I think I corrupted the memory of the task manager because I couldn't even use that to quit the mess. Could be a namespace issue... when freaking around with namespace too badly weird stuff can happen. Without having a look I wouldn't rule out that mr. Clemow made a typo or other minor error somewhere in there as that happens to the best of us.
I will send my code (and instructions on running it) to anyone who wants to take a look, but I'm afraid of subjecting the entire list to my spaghetti... ;-)
I definitely am not looking at that kind of ChucK code right now as I just turned in a fairly extensive sound design gig that I did in nearly pure ChucK but over my morning coffee tomorow (in 12 hours or so) would be fine. Just send it to my address and I'll have a look. No guarantees that I'll find it, of course, but clearly we need to get to the bottom of this. Kas.
Kas,
Ha! Thanks, Kas. I will investigate further for a few hours (I have
class in just a minute) and if I'm still stuck in this mess tonight
(in about 5 hours) I'll send it over. I think I've located in which
method contains the real problem, but it's only manifesting after 30
or so calls to these methods in unit tests, so it might just be
overloading the VM.
It's VERY likely there's a typo/mistake in my code (which is why I'm
testing it ;-) but the problem is finding it. Most of the time, calls
to these methods don't fail.
In the meantime, what exactly is a bus error? What generally causes them?
cheers,
-mike
On Wed, Sep 24, 2008 at 3:39 PM, Kassen
mike;
What is happening here? Is this a garbage collection issue?
I think ChucK has about as many garbage collection issues as I have problems understanding my grand-children...
Could definitely be something that has to do with memory, there are some issues there; just this morning I think I allocated too much memory too quickly (say 3/4th of a gig in parallel shreds) and the results weren't pretty; I think I corrupted the memory of the task manager because I couldn't even use that to quit the mess. Could be a namespace issue... when freaking around with namespace too badly weird stuff can happen. Without having a look I wouldn't rule out that mr. Clemow made a typo or other minor error somewhere in there as that happens to the best of us.
I will send my code (and instructions on running it) to anyone who wants to take a look, but I'm afraid of subjecting the entire list to my spaghetti... ;-)
I definitely am not looking at that kind of ChucK code right now as I just turned in a fairly extensive sound design gig that I did in nearly pure ChucK but over my morning coffee tomorow (in 12 hours or so) would be fine. Just send it to my address and I'll have a look. No guarantees that I'll find it, of course, but clearly we need to get to the bottom of this.
Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
mike; Ha! Thanks, Kas. I will investigate further for a few hours (I have
class in just a minute) and if I'm still stuck in this mess tonight (in about 5 hours) I'll send it over.
"Morning coffee" has arrived yet no code from you, perhaps you found it?
I think I've located in which method contains the real problem, but it's only manifesting after 30 or so calls to these methods in unit tests, so it might just be overloading the VM.
Quite odd. Overloading the VM should not cause errors like this. What's your CPU percentage doing? Are we seeing a crash as well? Is the Shred exiting?
It's VERY likely there's a typo/mistake in my code (which is why I'm testing it ;-) but the problem is finding it. Most of the time, calls to these methods don't fail.
Strange.
In the meantime, what exactly is a bus error? What generally causes them?
I had to search the "chuck" label in my inbox. I found several mentions of them and most were related to that old bug of initialising several variables on the same line or arrays. This makes me suspect we are dealing with something related to initialising memory, which would make sense given your description. If I had to place a bet now it would be that you are allocating memory in a way not anticipated by designers. If you have a "bus error" there is probably something wrong about ChucK as well, in possible adition to any errors you may have made. Mysterious, I'm quite curious now. Yours, Kas.
participants (2)
-
Kassen
-
mike clemow