Fellow ChucKists, I believe the code below demonstrates at least one bug that's keeping Mike from enjoying his spaghetti. There are definitely more related issues here but this is one. Appended non-primitive array locations can't be assigned to; clearly these are somehow different from array locations created when the array was created. Not creating a explicit "new" instance and instead appending a different instance directly also leads to reference issues, quite probably these are related. ================================= class Foo { int value; } Foo foo[8]; Foo bar; bar @=> foo[7]; foo << new Foo; <<<"all is fine so far", "">>>; Foo baz; <<<"everybody crash ChucK tonight", "">>>; baz @=> foo[8]; ================================ Yours, Kas.
Strangely, the following works fine. Must mean it's a garbage
collection issue, since in this case there remains in memory a
reference to the new Foo. If you add "baz @=> f;" to the end of this
script, it crashed, which proves it.
//=======================
class Foo
{
int value;
}
Foo foo[8];
Foo bar;
bar @=> foo[7];
new Foo @=> Foo @f;
foo << f;
<<<"all is fine so far", "">>>;
Foo baz;
<<<"everybody crash ChucK tonight", "">>>;
3::second => now;
baz @=> foo[8];
//=======================
On Sun, Sep 28, 2008 at 2:29 PM, Kassen
Fellow ChucKists,
I believe the code below demonstrates at least one bug that's keeping Mike from enjoying his spaghetti. There are definitely more related issues here but this is one. Appended non-primitive array locations can't be assigned to; clearly these are somehow different from array locations created when the array was created. Not creating a explicit "new" instance and instead appending a different instance directly also leads to reference issues, quite probably these are related.
================================= class Foo { int value; }
Foo foo[8];
Foo bar; bar @=> foo[7];
foo << new Foo;
<<<"all is fine so far", "">>>;
Foo baz;
<<<"everybody crash ChucK tonight", "">>>; baz @=> foo[8]; ================================
Yours, Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Stephen; Strangely, the following works fine. I'm increasingly suspecting "@" is ChucKian for saying "please" :¬).
Must mean it's a garbage collection issue, since in this case there remains in memory a reference to the new Foo.
I'm not surprised about that at all considering the error message talks about a reference count and Ge has mentioned using those for garbage collection. Great, so now we do have at least some garbage collection, even if it's not working perfectly yet. That's at least a silver lining.
If you add "baz @=> f;" to the end of this script, it crashed, which proves it.
Ok.... but I'd say that line should be valid as there *is* a rather clear reference to "f". This is kept track of as well because appending the file with "int f;" instead will give a (correct) complaint about "f" already having been defined in this scope. I can understand there being some bug left in the initialisation of apended array locations as those are new but calling a instance "f" is not new at all. It seems like there is something going wrong with the reference count in assignment as well or instead.
new Foo @=> Foo @f; foo << f;
Lovely. I'll take this to Mike's "spaghetti with spicy bug-sauce" and see how far that gets us. It's kinda ironical how civilisation has gotten us to the point where we can debate programing languages internationally over a electronic network yet we are still forced to organise hunting parties. Nice catch you got there. Cheers, Kas.
On Sun, Sep 28, 2008 at 4:39 PM, Kassen
Must mean it's a garbage collection issue, since in this case there remains in memory a reference to the new Foo.
I'm not surprised about that at all considering the error message talks about a reference count and Ge has mentioned using those for garbage collection.
Great, so now we do have at least some garbage collection, even if it's not working perfectly yet. That's at least a silver lining.
Yup, it probably needs some work, and at least I think reference-based garbage collection is a little easier to get right than the "hunt through memory for pointers" style. Though each has its own downsides if I recall, such as cyclical references.
If you add "baz @=> f;" to the end of this script, it crashed, which proves it.
Ok.... but I'd say that line should be valid as there *is* a rather clear reference to "f". This is kept track of as well because appending the file with "int f;" instead will give a (correct) complaint about "f" already having been defined in this scope. I can understand there being some bug left in the initialisation of apended array locations as those are new but calling a instance "f" is not new at all. It seems like there is something going wrong with the reference count in assignment as well or instead.
Well, I'm not sure if I understand what you're saying, but what's happening is that 'f' references a new Foo, and then that foo is added to the array. When it's later replaced, it's not garbage collected because 'f' still references it. But when 'f' is made to point somewhere else, *then* it gets garbage collected, which for some reason causes an exception. Appended 'int f' doesn't make much sense though since the problem doesn't lie with 'f', but with what 'f' points to. It'll just say that 'f' is already defined.
new Foo @=> Foo @f; foo << f;
Lovely. I'll take this to Mike's "spaghetti with spicy bug-sauce" and see how far that gets us.
It's kinda ironical how civilisation has gotten us to the point where we can debate programing languages internationally over a electronic network yet we are still forced to organise hunting parties. Nice catch you got there.
Ha. :) Steve
Steve; Yup, it probably needs some work, and at least I think reference-based
garbage collection is a little easier to get right than the "hunt through memory for pointers" style. Though each has its own downsides if I recall, such as cyclical references.
Well, anything is better then clogging up the whole CPU with periodic collection; we can't afford that.
Well, I'm not sure if I understand what you're saying, but what's happening is that 'f' references a new Foo, and then that foo is added to the array. When it's later replaced, it's not garbage collected because 'f' still references it. But when 'f' is made to point somewhere else, *then* it gets garbage collected, which for some reason causes an exception.
Appended 'int f' doesn't make much sense though since the problem doesn't lie with 'f', but with what 'f' points to. It'll just say that 'f' is already defined.
I may have made a reasoning error but I wanted to test to see whether when the object under "f" is collected the reference, named "f", was still there. I knew this was a naive test but still wanted to run it. We're definitely having some kind of big-ish trouble here; I just saw ChucK spew out a amount of data at crashing. I've never seen it do anything like this before. Pasted below in case it means something to someone. At least I now got Mike's Unit-tests to go beyond where his comments say it gives a "bus error"... out of the frying pan and into the fire. I archived the state the code was in at this point in case this is relevant; zip-file on request. Yours, Kas. --------------------start paste---------------------------- *** glibc detected *** chuck: double free or corruption (!prev): 0x0842b7e8 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb7bf2a85] /lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7bf64f0] /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb7e1eb11] /usr/lib/libstdc++.so.6(_ZdaPv+0x1d)[0xb7e1eb6d] chuck[0x8055f6f] chuck[0x80596da] chuck[0x809a652] chuck[0x805944e] chuck[0x80594d2] chuck[0x80c4ed5] chuck[0x80d2048] chuck[0x80cc8e8] /lib/tls/i686/cmov/libpthread.so.0[0xb7b744fb] /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7c5de5e] ======= Memory map: ======== 08048000-081ac000 r-xp 00000000 08:01 1165811 /usr/bin/chuck 081ac000-081d3000 rw-p 00164000 08:01 1165811 /usr/bin/chuck 081d3000-0845c000 rw-p 081d3000 00:00 0 [heap] b6200000-b6221000 rw-p b6200000 00:00 0 b6221000-b6300000 ---p b6221000 00:00 0 b6311000-b6312000 ---p b6311000 00:00 0 b6312000-b6b12000 rw-p b6312000 00:00 0 b6b12000-b6b13000 ---p b6b12000 00:00 0 b6b13000-b7313000 rw-p b6b13000 00:00 0 b7313000-b7314000 ---p b7313000 00:00 0 b7314000-b7b16000 rw-p b7314000 00:00 0 b7b16000-b7b1a000 r-xp 00000000 08:01 1165578 /usr/lib/libogg.so.0.5.3 b7b1a000-b7b1b000 rw-p 00003000 08:01 1165578 /usr/lib/libogg.so.0.5.3 b7b1b000-b7b6e000 r-xp 00000000 08:01 1165787 /usr/lib/libFLAC.so.8.2.0 b7b6e000-b7b6f000 rw-p 00052000 08:01 1165787 /usr/lib/libFLAC.so.8.2.0 b7b6f000-b7b83000 r-xp 00000000 08:01 3965681 /lib/tls/i686/cmov/ libpthread-2.7.so b7b83000-b7b85000 rw-p 00013000 08:01 3965681 /lib/tls/i686/cmov/ libpthread-2.7.so b7b85000-b7b87000 rw-p b7b85000 00:00 0 b7b87000-b7cd0000 r-xp 00000000 08:01 3965649 /lib/tls/i686/cmov/ libc-2.7.so b7cd0000-b7cd1000 r--p 00149000 08:01 3965649 /lib/tls/i686/cmov/ libc-2.7.so b7cd1000-b7cd3000 rw-p 0014a000 08:01 3965649 /lib/tls/i686/cmov/ libc-2.7.so b7cd3000-b7cd7000 rw-p b7cd3000 00:00 0 b7cd7000-b7ce1000 r-xp 00000000 08:01 3932228 /lib/libgcc_s.so.1 b7ce1000-b7ce2000 rw-p 0000a000 08:01 3932228 /lib/libgcc_s.so.1 b7ce2000-b7d05000 r-xp 00000000 08:01 3965653 /lib/tls/i686/cmov/ libm-2.7.so b7d05000-b7d07000 rw-p 00023000 08:01 3965653 /lib/tls/i686/cmov/ libm-2.7.so b7d07000-b7d5d000 r-xp 00000000 08:01 1165274 /usr/lib/libsndfile.so.1.0.17 b7d5d000-b7d5e000 rw-p 00056000 08:01 1165274 /usr/lib/libsndfile.so.1.0.17 b7d5e000-b7d63000 rw-p b7d5e000 00:00 0 b7d63000-b7d65000 r-xp 00000000 08:01 3965652 /lib/tls/i686/cmov/ libdl-2.7.so b7d65000-b7d67000 rw-p 00001000 08:01 3965652 /lib/tls/i686/cmov/ libdl-2.7.so b7d67000-b7e4f000 r-xp 00000000 08:01 1164012 /usr/lib/libstdc++.so.6.0.9 b7e4f000-b7e52000 r--p 000e8000 08:01 1164012 /usr/lib/libstdc++.so.6.0.9 b7e52000-b7e54000 rw-p 000eb000 08:01 1164012 /usr/lib/libstdc++.so.6.0.9 b7e54000-b7e5a000 rw-p b7e54000 00:00 0 b7e5a000-b7f19000 r-xp 00000000 08:01 1165782 /usr/lib/libasound.so.2.0.0 b7f19000-b7f1d000 rw-p 000be000 08:01 1165782 /usr/lib/libasound.so.2.0.0 b7f1d000-b7f1e000 rw-p b7f1d000 00:00 0 b7f2b000-b7f2c000 rw-s 81000000 00:0e 11361 /dev/snd/pcmC0D0c b7f2c000-b7f2d000 r--s 80000000 00:0e 11361 /dev/snd/pcmC0D0c b7f2d000-b7f2e000 rw-s 81000000 00:0e 11354 /dev/snd/pcmC0D0p b7f2e000-b7f2f000 r--s 80000000 00:0e 11354 /dev/snd/pcmC0D0p b7f2f000-b7f30000 rw-p b7f2f000 00:00 0 b7f30000-b7f31000 r-xp b7f30000 00:00 0 [vdso] b7f31000-b7f4b000 r-xp 00000000 08:01 3932197 /lib/ld-2.7.so b7f4b000-b7f4d000 rw-p 00019000 08:01 3932197 /lib/ld-2.7.so bfbe3000-bfbf8000 rw-p bffeb000 00:00 0 [stack] Aborted --------------------------end paste------------------------
The garbage collection dicussion is way over my head at this point,
however, I want to thank you guys for taking a look at this issue.
The stack trace seems to be a lot more information than "bus error"
is. I hope that Ge can make some sense of the underlying issues.
Back to my spaghetti...
Cheers,
Mike
On Sun, Sep 28, 2008 at 6:31 PM, Kassen
Steve;
Yup, it probably needs some work, and at least I think reference-based garbage collection is a little easier to get right than the "hunt through memory for pointers" style. Though each has its own downsides if I recall, such as cyclical references.
Well, anything is better then clogging up the whole CPU with periodic collection; we can't afford that.
Well, I'm not sure if I understand what you're saying, but what's happening is that 'f' references a new Foo, and then that foo is added to the array. When it's later replaced, it's not garbage collected because 'f' still references it. But when 'f' is made to point somewhere else, *then* it gets garbage collected, which for some reason causes an exception.
Appended 'int f' doesn't make much sense though since the problem doesn't lie with 'f', but with what 'f' points to. It'll just say that 'f' is already defined.
I may have made a reasoning error but I wanted to test to see whether when the object under "f" is collected the reference, named "f", was still there. I knew this was a naive test but still wanted to run it.
We're definitely having some kind of big-ish trouble here; I just saw ChucK spew out a amount of data at crashing. I've never seen it do anything like this before. Pasted below in case it means something to someone. At least I now got Mike's Unit-tests to go beyond where his comments say it gives a "bus error"... out of the frying pan and into the fire. I archived the state the code was in at this point in case this is relevant; zip-file on request.
Yours, Kas.
--------------------start paste---------------------------- *** glibc detected *** chuck: double free or corruption (!prev): 0x0842b7e8 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb7bf2a85] /lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7bf64f0] /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb7e1eb11] /usr/lib/libstdc++.so.6(_ZdaPv+0x1d)[0xb7e1eb6d] chuck[0x8055f6f] chuck[0x80596da] chuck[0x809a652] chuck[0x805944e] chuck[0x80594d2] chuck[0x80c4ed5] chuck[0x80d2048] chuck[0x80cc8e8] /lib/tls/i686/cmov/libpthread.so.0[0xb7b744fb] /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7c5de5e] ======= Memory map: ======== 08048000-081ac000 r-xp 00000000 08:01 1165811 /usr/bin/chuck 081ac000-081d3000 rw-p 00164000 08:01 1165811 /usr/bin/chuck 081d3000-0845c000 rw-p 081d3000 00:00 0 [heap] b6200000-b6221000 rw-p b6200000 00:00 0 b6221000-b6300000 ---p b6221000 00:00 0 b6311000-b6312000 ---p b6311000 00:00 0 b6312000-b6b12000 rw-p b6312000 00:00 0 b6b12000-b6b13000 ---p b6b12000 00:00 0 b6b13000-b7313000 rw-p b6b13000 00:00 0 b7313000-b7314000 ---p b7313000 00:00 0 b7314000-b7b16000 rw-p b7314000 00:00 0 b7b16000-b7b1a000 r-xp 00000000 08:01 1165578 /usr/lib/libogg.so.0.5.3 b7b1a000-b7b1b000 rw-p 00003000 08:01 1165578 /usr/lib/libogg.so.0.5.3 b7b1b000-b7b6e000 r-xp 00000000 08:01 1165787 /usr/lib/libFLAC.so.8.2.0 b7b6e000-b7b6f000 rw-p 00052000 08:01 1165787 /usr/lib/libFLAC.so.8.2.0 b7b6f000-b7b83000 r-xp 00000000 08:01 3965681 /lib/tls/i686/cmov/libpthread-2.7.so b7b83000-b7b85000 rw-p 00013000 08:01 3965681 /lib/tls/i686/cmov/libpthread-2.7.so b7b85000-b7b87000 rw-p b7b85000 00:00 0 b7b87000-b7cd0000 r-xp 00000000 08:01 3965649 /lib/tls/i686/cmov/libc-2.7.so b7cd0000-b7cd1000 r--p 00149000 08:01 3965649 /lib/tls/i686/cmov/libc-2.7.so b7cd1000-b7cd3000 rw-p 0014a000 08:01 3965649 /lib/tls/i686/cmov/libc-2.7.so b7cd3000-b7cd7000 rw-p b7cd3000 00:00 0 b7cd7000-b7ce1000 r-xp 00000000 08:01 3932228 /lib/libgcc_s.so.1 b7ce1000-b7ce2000 rw-p 0000a000 08:01 3932228 /lib/libgcc_s.so.1 b7ce2000-b7d05000 r-xp 00000000 08:01 3965653 /lib/tls/i686/cmov/libm-2.7.so b7d05000-b7d07000 rw-p 00023000 08:01 3965653 /lib/tls/i686/cmov/libm-2.7.so b7d07000-b7d5d000 r-xp 00000000 08:01 1165274 /usr/lib/libsndfile.so.1.0.17 b7d5d000-b7d5e000 rw-p 00056000 08:01 1165274 /usr/lib/libsndfile.so.1.0.17 b7d5e000-b7d63000 rw-p b7d5e000 00:00 0 b7d63000-b7d65000 r-xp 00000000 08:01 3965652 /lib/tls/i686/cmov/libdl-2.7.so b7d65000-b7d67000 rw-p 00001000 08:01 3965652 /lib/tls/i686/cmov/libdl-2.7.so b7d67000-b7e4f000 r-xp 00000000 08:01 1164012 /usr/lib/libstdc++.so.6.0.9 b7e4f000-b7e52000 r--p 000e8000 08:01 1164012 /usr/lib/libstdc++.so.6.0.9 b7e52000-b7e54000 rw-p 000eb000 08:01 1164012 /usr/lib/libstdc++.so.6.0.9 b7e54000-b7e5a000 rw-p b7e54000 00:00 0 b7e5a000-b7f19000 r-xp 00000000 08:01 1165782 /usr/lib/libasound.so.2.0.0 b7f19000-b7f1d000 rw-p 000be000 08:01 1165782 /usr/lib/libasound.so.2.0.0 b7f1d000-b7f1e000 rw-p b7f1d000 00:00 0 b7f2b000-b7f2c000 rw-s 81000000 00:0e 11361 /dev/snd/pcmC0D0c b7f2c000-b7f2d000 r--s 80000000 00:0e 11361 /dev/snd/pcmC0D0c b7f2d000-b7f2e000 rw-s 81000000 00:0e 11354 /dev/snd/pcmC0D0p b7f2e000-b7f2f000 r--s 80000000 00:0e 11354 /dev/snd/pcmC0D0p b7f2f000-b7f30000 rw-p b7f2f000 00:00 0 b7f30000-b7f31000 r-xp b7f30000 00:00 0 [vdso] b7f31000-b7f4b000 r-xp 00000000 08:01 3932197 /lib/ld-2.7.so b7f4b000-b7f4d000 rw-p 00019000 08:01 3932197 /lib/ld-2.7.so bfbe3000-bfbf8000 rw-p bffeb000 00:00 0 [stack] Aborted
--------------------------end paste------------------------
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
participants (3)
-
Kassen -
mike clemow -
Stephen Sinclair