severe ChucK v1.3.0.0 bug
system: rhaberkorn@nb005-lx001:~$ uname -a Linux nb005-lx001 2.6.32-42-generic #95-Ubuntu SMP Wed Jul 25 15:56:09 UTC 2012 x86_64 GNU/Linux rhaberkorn@nb005-lx001:~$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=10.04 DISTRIB_CODENAME=lucid DISTRIB_DESCRIPTION="Ubuntu 10.04.4 LTS" I'm using a ChucK build with my own modifications (-m32 and some that are Jack-related). test case: fun void foo(string s) { //<<< s >>>; } while (true) { //<<< 1 >>>; "bar" => foo; //<<< 2 >>>; } result: rhaberkorn@nb005-lx001:~$ chuck --srate:44100 bug.ck chuck: chuck_oo.cpp:125: void Chuck_VM_Object::release(): Assertion `m_ref_count > 0' failed. Aborted uncommenting the debug prints: rhaberkorn@nb005-lx001:~$ chuck-1.3.0.0/src/chuck --srate:44100 bug.ck 1 :(int) "bar" : (string) 2 :(int) 1 :(int) "bar" : (string) Segmentation fault (core dumped) rhaberkorn@nb005-lx001:~$ gdb ./chuck-1.3.0.0/src/chuck ./core GNU gdb (GDB) 7.1-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/rhaberkorn/chuck-1.3.0.0/src/chuck...done. [New Thread 1192] [New Thread 1199] [New Thread 1198] [New Thread 1193] [New Thread 1200] warning: Can't read pathname for load map: Input/output error. Reading symbols from /usr/lib32/libasound.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib32/libasound.so.2 Reading symbols from /usr/local/lib32/libjack.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib32/libjack.so.0 Reading symbols from /usr/lib32/libstdc++.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib32/libstdc++.so.6 Reading symbols from /lib32/libdl.so.2...Reading symbols from /usr/lib/debug/lib32/libdl-2.11.1.so...done. done. Loaded symbols for /lib32/libdl.so.2 Reading symbols from /lib32/libpthread.so.0...Reading symbols from /usr/lib/debug/lib32/libpthread-2.11.1.so...done. done. Loaded symbols for /lib32/libpthread.so.0 Reading symbols from /usr/lib32/libFLAC.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib32/libFLAC.so.8 Reading symbols from /usr/lib32/libogg.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib32/libogg.so.0 Reading symbols from /usr/lib32/libvorbis.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib32/libvorbis.so.0 Reading symbols from /usr/lib32/libvorbisenc.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib32/libvorbisenc.so.2 Reading symbols from /lib32/libm.so.6...Reading symbols from /usr/lib/debug/lib32/libm-2.11.1.so...done. done. Loaded symbols for /lib32/libm.so.6 Reading symbols from /usr/lib32/libgcc_s.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib32/libgcc_s.so.1 Reading symbols from /lib32/libc.so.6...Reading symbols from /usr/lib/debug/lib32/libc-2.11.1.so...done. done. Loaded symbols for /lib32/libc.so.6 Reading symbols from /lib32/librt.so.1...Reading symbols from /usr/lib/debug/lib32/librt-2.11.1.so...done. done. Loaded symbols for /lib32/librt.so.1 Reading symbols from /usr/lib32/libcelt0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib32/libcelt0.so.0 Reading symbols from /lib/ld-linux.so.2... warning: the debug information found in "/lib/ld-2.11.1.so" does not match "/lib/ld-linux.so.2" (CRC mismatch). warning: the debug information found in "/usr/lib/debug//lib/ld-2.11.1.so" does not match "/lib/ld-linux.so.2" (CRC mismatch). warning: the debug information found in "/usr/lib/debug/lib/ld-2.11.1.so" does not match "/lib/ld-linux.so.2" (CRC mismatch). (no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Core was generated by `chuck-1.3.0.0/src/chuck --srate:44100 bug.ck'. Program terminated with signal 11, Segmentation fault. #0 0x080ab3c8 in Chuck_VM_Alloc::free_object (this=0x8491028, obj=0x85d1108) at chuck_oo.cpp:259 259 delete obj; (gdb) bt #0 0x080ab3c8 in Chuck_VM_Alloc::free_object (this=0x8491028, obj=0x85d1108) at chuck_oo.cpp:259 #1 0x080ab1f4 in Chuck_VM_Object::release (this=0x85d1108) at chuck_oo.cpp:148 #2 0x08069abb in Chuck_Instr_Release_Object2::execute (this=0x85d1c40, vm=0x8491780, shred=0x85d1f58) at chuck_instr.cpp:3232 #3 0x0805ba3f in Chuck_VM_Shred::run (this=0x85d1f58, vm=0x8491780) at chuck_vm.cpp:1677 #4 0x08059492 in Chuck_VM::compute (this=0x8491780) at chuck_vm.cpp:655 #5 0x080593d9 in Chuck_VM::run (this=0x8491780) at chuck_vm.cpp:602 #6 0x080c952a in main (argc=3, argv=0xffaeda04) at chuck_main.cpp:969 (gdb)
On 29/08/12 02:52, Robin Haberkorn wrote:
... uncommenting the debug prints:
rhaberkorn@nb005-lx001:~$ chuck-1.3.0.0/src/chuck --srate:44100 bug.ck 1 :(int) "bar" : (string) 2 :(int) 1 :(int) "bar" : (string) Segmentation fault (core dumped) ...
this was actually using foo("bar") instead of "bar" => foo (the behaviour is a little bit different)
Hi Robin! Ah yes, this is a bug that came out of our updated, slightly less dumb reference counting. Will fix and we will roll out an update soon! Nice catch! Thanks! Ge! On Wed, 29 Aug 2012, Robin Haberkorn wrote:
On 29/08/12 02:52, Robin Haberkorn wrote:
... uncommenting the debug prints:
rhaberkorn@nb005-lx001:~$ chuck-1.3.0.0/src/chuck --srate:44100 bug.ck 1 :(int) "bar" : (string) 2 :(int) 1 :(int) "bar" : (string) Segmentation fault (core dumped) ...
this was actually using foo("bar") instead of "bar" => foo (the behaviour is a little bit different) _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Hi Ge! Nice to hear there will be a bug fix release soon. I'm quite excited about the new version and its features. Unfortunately every time I try to make noises with ChucK I end up finding bugs and working around them - instead of making noises. You can find some examples in my Git repo: https://github.com/rhaberkorn/digitale-debutanten I think that stability has to be improved even before performance. A bug tracker and a *simple* test suite (language features and regression tests) would be a nice first step. Any plans on doing this? cheers, Robin On 29/08/12 08:34, Ge Wang wrote:
Hi Robin!
Ah yes, this is a bug that came out of our updated, slightly less dumb reference counting. Will fix and we will roll out an update soon! Nice catch! Thanks!
Ge!
On Wed, 29 Aug 2012, Robin Haberkorn wrote:
On 29/08/12 02:52, Robin Haberkorn wrote:
... uncommenting the debug prints:
rhaberkorn@nb005-lx001:~$ chuck-1.3.0.0/src/chuck --srate:44100 bug.ck 1 :(int) "bar" : (string) 2 :(int) 1 :(int) "bar" : (string) Segmentation fault (core dumped) ...
this was actually using foo("bar") instead of "bar" => foo (the behaviour is a little bit different) _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
try that one: fun void foo(string s) { <<< s >>>; } "bar" => string s; while (true) s => foo; It's not only affecting string constants as I first suspected. This breaks a lot of my functions where one variable is passed to another function multiple times. I assume that the string value reference is released on foo() return but not increased when passing it to foo(). Could you drop a note when the fix hits SVN so I can import it into my ChucK Git repository? cheers, Robin On 29/08/12 08:34, Ge Wang wrote:
Hi Robin!
Ah yes, this is a bug that came out of our updated, slightly less dumb reference counting. Will fix and we will roll out an update soon! Nice catch! Thanks!
Ge!
On Wed, 29 Aug 2012, Robin Haberkorn wrote:
On 29/08/12 02:52, Robin Haberkorn wrote:
... uncommenting the debug prints:
rhaberkorn@nb005-lx001:~$ chuck-1.3.0.0/src/chuck --srate:44100 bug.ck 1 :(int) "bar" : (string) 2 :(int) 1 :(int) "bar" : (string) Segmentation fault (core dumped) ...
this was actually using foo("bar") instead of "bar" => foo (the behaviour is a little bit different) _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
A bug tracker and a *simple* test suite (language features and regression tests) would be a nice first step. Any plans on doing this?
That might be a chuck-dev complaint.
Could you drop a note when the fix hits SVN so I can import it into my ChucK Git repository?
That might be obnoxious.
--
Al Matthews
http://fatmilktv.com
On Wed, Aug 29, 2012 at 8:48 AM, Robin Haberkorn
try that one:
fun void foo(string s) { <<< s >>>; }
"bar" => string s;
while (true) s => foo;
It's not only affecting string constants as I first suspected. This breaks a lot of my functions where one variable is passed to another function multiple times. I assume that the string value reference is released on foo() return but not increased when passing it to foo().
Could you drop a note when the fix hits SVN so I can import it into my ChucK Git repository?
cheers, Robin
On 29/08/12 08:34, Ge Wang wrote:
Hi Robin!
Ah yes, this is a bug that came out of our updated, slightly less dumb reference counting. Will fix and we will roll out an update soon! Nice catch! Thanks!
Ge!
On Wed, 29 Aug 2012, Robin Haberkorn wrote:
On 29/08/12 02:52, Robin Haberkorn wrote:
... uncommenting the debug prints:
rhaberkorn@nb005-lx001:~$ chuck-1.3.0.0/src/chuck --srate:44100 bug.ck 1 :(int) "bar" : (string) 2 :(int) 1 :(int) "bar" : (string) Segmentation fault (core dumped) ...
this was actually using foo("bar") instead of "bar" => foo (the behaviour is a little bit different) _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- Al Matthews
On 29/08/12 14:53, Al Matthews wrote:
A bug tracker and a *simple* test suite (language features and regression tests) would be a nice first step. Any plans on doing this?
That might be a chuck-dev complaint.
Could you drop a note when the fix hits SVN so I can import it into my ChucK Git repository?
That might be obnoxious.
Sorry if that sounded strange (I'm not a native speaker). However I've seen the new release and it already fixes the bug. So thanks!
Robin;
fun void foo(string s) { <<< s >>>; } I assume that the string value reference is released on foo() return but not increased when passing it to foo().
Yes, me too. That happens though it's not always easy to predict when it will happen. fun void foo(string @ s) {stuff.... ...would sometimes fix it, I seem to remember. This technique is known as "sprinkling in some more @ signs" in professional terms. ;-) Yours, Kas.
Unfortunately, you cannot even declare references to the primitive types like strings. The compiler complains when you do that... On 29/08/12 18:37, Kassen wrote:
Robin;
fun void foo(string s) { <<< s >>>; } I assume that the string value reference is released on foo() return but not increased when passing it to foo().
Yes, me too. That happens though it's not always easy to predict when it will happen. fun void foo(string @ s) {stuff....
...would sometimes fix it, I seem to remember. This technique is known as "sprinkling in some more @ signs" in professional terms.
;-)
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
participants (4)
-
Al Matthews -
Ge Wang -
Kassen -
Robin Haberkorn