- chuck-dev - lists.cs.princeton.edu

RT safeness check
by Florian Schmidt 29 Oct '05

29 Oct '05

Hi, i lately updated the chuck cvs repository and tried to run jackd with Preemption checking enabled (this tells us about whenever chuck's process() callback is preempted due to it using a blocking system call (a no-no in jackd process callbacks, unless you want to provoke xruns eventually)): Test scenario: jackd -R -C -d alsa -d hw:1 -p 128 The -C option enables preemption checking provided that a] jackd was built with --enable-preemption-check b] a realtime preemption kernel is running with latency tracing enabled ~/source/build_stuff/chuck_dev/v2/examples$ ../chuck -p9999 --loop ~/source/build_stuff/chuck_dev/v2/examples$ chuck -p9999 + otf_01.ck running otf_01.ck it seems some code is doing fs access (loading the .wav file maybe?): [ 412.026048] chuck:1995 userspace BUG: scheduling in user-atomic context! [ 412.026074] [<c01039ef>] dump_stack+0x1f/0x30 (20) [ 412.026098] [<c03029c7>] schedule+0x107/0x130 (28) [ 412.026122] [<c0303313>] io_schedule+0x13/0x20 (8) [ 412.026136] [<c01497cc>] sync_page+0x3c/0x50 (12) [ 412.026159] [<c030358a>] __wait_on_bit_lock+0x4a/0x70 (32) [ 412.026173] [<c014a034>] __lock_page+0x54/0x60 (44) [ 412.026185] [<c014a7cd>] do_generic_mapping_read+0x2fd/0x6e0 (132) [ 412.026199] [<c014ad98>] __generic_file_aio_read+0xe8/0x250 (100) [ 412.026212] [<c014af57>] generic_file_aio_read+0x57/0x90 (44) [ 412.026225] [<c016ad7a>] do_sync_read+0xba/0x110 (160) [ 412.026239] [<c016ae95>] vfs_read+0xc5/0x1b0 (40) [ 412.026251] [<c016b28c>] sys_read+0x4c/0x80 (44) [ 412.026263] [<c0103386>] syscall_call+0x7/0xb (-8116) [ 412.026276] --------------------------- [ 412.026283] | preempt count: 00000000 ] [ 412.026289] | 0-level deep critical section nesting: [ 412.026295] ---------------------------------------- [ 412.026302] [ 412.026307] ------------------------------ [ 412.026313] | showing all locks held by: | (chuck/1995 [ee6630c0, 90]): [ 412.026326] ------------------------------ [ 412.026333] Here's a bt (dunno how useful that is): (gdb) set arg -p9999 --loop (gdb) run Starting program: /home/tapas/source/build_stuff/chuck_dev/v2/chuck -p9999 --loo p [Thread debugging using libthread_db enabled] [New Thread -1212279104 (LWP 2147)] [New Thread -1212347472 (LWP 2151)] [New Thread -1220736080 (LWP 2152)] [chuck](VM): sporking incoming shred: 1 (otf_01.ck)... Program received signal SIGUSR2, User defined signal 2. [Switching to Thread -1220736080 (LWP 2152)] 0xb7cf5481 in read () from /lib/tls/libc.so.6 (gdb) bt #0 0xb7cf5481 in read () from /lib/tls/libc.so.6 #1 0xb7d82e13 in sf_open () from /usr/lib/libsndfile.so.1 #2 0xb7d814e6 in sf_open () from /usr/lib/libsndfile.so.1 #3 0xb7d81b2a in sf_open () from /usr/lib/libsndfile.so.1 #4 0xb7dac655 in sf_open () from /usr/lib/libsndfile.so.1 #5 0xb7d7f8eb in sf_close () from /usr/lib/libsndfile.so.1 #6 0xb7d8017f in sf_open () from /usr/lib/libsndfile.so.1 #7 0x08115a91 in sndbuf_ctrl_read () #8 0x0805fc9c in Chuck_Instr_Func_Call_Member::execute () #9 0x08058df2 in Chuck_VM::compute () #10 0x08058ed7 in Chuck_VM::run () #11 0x080b3ebd in Digitalio::cb2 () #12 0x080c4426 in RtApiJack::callbackEvent () #13 0x080c45b6 in jackCallbackHandler () #14 0xb7ed9a59 in jack_client_close () from /usr/lib/libjack-0.100.0.so.0 #15 0xb7edd3d3 in jack_acquire_real_time_scheduling () from /usr/lib/libjack-0.100.0.so.0 #16 0xb7c26cfd in start_thread () from /lib/tls/libpthread.so.0 #17 0xb7d04f1e in clone () from /lib/tls/libc.so.6 It seems every chuck program of the otf example series that loads a .wav file makes chuck do some file access in the process callback (which potentially blocks). otf_06.ck and others seem to get executed just fine. I did run the tests for relatively short times though, so it might as well happen that more pops up lateron. I will leave the otf_05 and otf_06 running all afternoon (i'll be gone for rehearsal).. Do you have any certain example programs in mind which i could test for RT safeness? Have fun, Flo -- Palimm Palimm! http://tapas.affenbande.org

1 0

Build problem for 1.2.0.3
by Erik de Castro Lopo 23 Oct '05

23 Oct '05

Hi all, Trying to build 1.2.0.3 and get: erikd@miles > make linux-alsa make -f makefile.alsa make[1]: Entering directory `/home/erikd/chuck-1.2.0.3/src' bison -dv -b chuck chuck.y gcc -D__LINUX_ALSA__ -O3 -c -D__CK_SNDFILE_NATIVE__ chuck.tab.c flex -ochuck.yy.c chuck.lex gcc -D__LINUX_ALSA__ -O3 -c -D__CK_SNDFILE_NATIVE__ chuck.yy.c chuck.lex: In function 'comment': chuck.lex:246: warning: comparison is always true due to limited range of data type chuck.lex: In function 'block_comment': chuck.lex:262: warning: comparison is always true due to limited range of data type chuck.lex:272: warning: comparison is always false due to limited range of data type chuck.lex:280: error: 'yytext_ptr' undeclared (first use in this function) chuck.lex:280: error: (Each undeclared identifier is reported only once chuck.lex:280: error: for each function it appears in.) make[1]: *** [chuck.yy.o] Error 1 make[1]: Leaving directory `/home/erikd/chuck-1.2.0.3/src' make: [linux-alsa] Error 2 (ignored) The system is an Apple iBook running Debian testing. Versions of stuff are as follows: erikd@miles > gcc --version gcc (GCC) 4.0.2 (Debian 4.0.2-2) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. erikd@miles > flex --version flex 2.5.31 erikd@miles > bison --version bison (GNU Bison) 1.875d Written by Robert Corbett and Richard Stallman. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Even Napoleon had his Watergate" -- Michael Spautz -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "No Silicon Heaven? Preposterous! Where would all the calculators go?" -- Kryten, Red Dwarf

2 3

A couple of bugs (example programs)
by Erik de Castro Lopo 22 Oct '05

22 Oct '05

Hi all, I'm playing with some of the example programs shipped with chuck and see the following: erikd@miles > chuck -r44100 hanoi.ck Segmentation fault and: erikd@miles > chuck -r44100 hanoi++.ck move disk from peg 1 -> peg 2 move disk from peg 1 -> peg 3 move disk from peg 2 -> peg 3 .... .... move disk from peg 1 -> peg 3 move disk from peg 2 -> peg 3 "done!" : (string) *** glibc detected *** double free or corruption (!prev): 0x103158f0 *** Aborted Are the chuck developers aware of valgrind ( http://valgrind.kde.org/ )? Its a really useful tool for tracking down a sqashing bugs like this before thy result in things like seg fauls. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "Even Napoleon had his Watergate" -- Michael Spautz -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "These are the finest moments in (post)modern life, when satire is completly indistinguishable from reality... I usually have to rely on the presidential elections for such dada." -- frenomulax on Jesux a christian Linux distro.

1 0

[patch] Editing the manual
by Graham Percival 19 Oct '05

19 Oct '05

Hi all, Attached are three diffs for the manual, made from the top directory of the CVS tree. I plan on editing the rest of the manual, so let me know if you'd prefer the diffs in a different format. These are almost all typo fixes. Cheers, - Graham

1 0

[patch] adds --version (minor cosmetic)
by Graham Percival 17 Oct '05

17 Oct '05

I noticed that chuck does not recognize "--version" ; many unix programs support this. This patch adds --version. A trivial, cosmetic thing to be sure, but it might be useful to have. :) The patch was created against the 1.2.0.1 tarball. Cheers, - Graham Percival

2 1

Cannot Initialize Audio Device (chuck-1.2.0.1)
by Esben Stien 06 Oct '05

06 Oct '05

Compiled with jack, chuck status yields: [chuck]: RtApi: no devices found for given stream parameters. [chuck]: cannot initialize audio device (try using --silent/-s Same with any file.. Any pointers on how to proceed? (linux-2.6.14-rc2-rt7, jack-0.100.1) -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n

2 4

[patch] adds DESTDIR to the makefile
by Graham Percival 04 Oct '05

04 Oct '05

I always install programs in $HOME/usr/bin ; this is easy to do with chuck, but I have to change the makefile in two different places. (it's a tough life, right? :) This patch abstracts the install directory with a DESTDIR variable, so users only need to change it once. Patch created against the 1.2.0.1 source tarball. Cheers, - Graham Percival

1 0

JACK correctness part IX (callback vs. blocking)
by Ge Wang 28 Sep '05

28 Sep '05

Greetings! On the recommendation of Dave Robillard, Florian Schmidt, and other Linux audio developers, we have implemented callback functionality for real-time audio, while keeping the blocking functionality. Both are accessible using command line flags (--callback vs. --blocking). The default is callback. Perhaps not surprisingly, this is much more stable for small buffersize on all platforms except windows directsound. Hopefully, it is a step in the right direction for alleviating problems running chuck under Linux/JACK. The newest version is in CVS: cvs -d :ext:anon-chuck@cvs.cs.princeton.edu:/cvs checkout chuck_dev password: (hit enter) The code is in chuck_dev/v2/ I must admit that I don't know Jack and would like to ask Linux/Jack users here to give it a spin under various conditions. Please let us know how things fare. Dave, Florian, Leonard - can you guys give this a try? Thank you very much! Best, Ge!

3 3

Bug+Fix: Various combinations of virtual functions and base-class variable references fail.
by Robin Davies 26 Sep '05

26 Sep '05

Problem: Various legal constructs in extended classes fail to compile, particularly references to base class members and methods. References to global variables in constructor code also fails. See the test file given below. Fix: chuck-emit.cpp line 3303 delete 3303 < assert( v->owner_class == emit->env->class_def ); chuck-type.cpp line 1758 < if( !env->class_def || env->class_scope > 0 ) > if( !env->class_def) Discussion: The assert is incorrect. The reference may be to a base-class member, (or perhaps a global variable. I'm not sure about that). It may be better to replace the assert with something like: assert(is_parent_type(emit->env->class_def,v->owner_class) || is_global_type(v->owner_class) ) (neither function currently avaialble). The second fix is more difficult. Generally, we want the test to fail and go to the else clause which searches class scope for the variable if we're in a class definition. I don't understand the purpose of the test on class_scope, which is certainly incorrect, whatever it's supposed to do. What I do know: class_scope is zero in constructor code, and increments for each nested scope (function, code block &c) in the code at this point. If the intention is to prevent references to base class or global variables in constructure code, then it would be "env->class_scope == 0" (sense inverted); but this seems like an arbitrary restriction on a perfectly useful functionality, and removing the test altogether doesn't seem to cause problems in code generation. References to global variables and variables in the current scope seem to be caught before this (which, thinking about it, suggests that global variable references will take precedence over base-class references, which is incorrect -- possibly another bug). The main issue seems to be base-class references. Deleting the || test seems to correct the scanning pass, and the generated code passes the test case given below. With respect to global and base-class variables with the same name, I wrote a test for this case (see ScopeTest-11 tests below). The test succeeds, with the above patches applied. Both type checking and code generation seem to work. So I'm not going to hunt further. Test case for the fix: ScopeTest.ck ///////////////////////////// // ScopeTest.ck // Test Scoping of variables and virtual functions in extended classes. // ///////////////////////////// function void Assert(int condition, string message) { if (!condition) { <<< "Assert Failed: ", message >>>; } } 1 => int globalVariable; Assert(globalVariable == 1,"ScopeTest-1 Global Assignment"); string globalAndBaseclassVariable; class Base { int globalAndBaseclassVariable; 2 => globalVariable; Assert(globalVariable == 2,"ScopeTest-2 Global Assignment from constructor."); 3 => int v; Assert(v == 3,"ScopeTest-3 Assigment to class variable in ctor"); function int GetV() { return v; } function int GetVVirtual() { return v; } } class Super extends Base { 4 => int v2; Assert(v2 == 4,"ScopeTest-4 Assigment to class scope from extended class."); 5 => v; Assert(v == 5, "ScopeTest-5 Assignment to variable in superclass."); 6 => v; Assert(GetV() == 6, "ScopeTest-6 Assignment to variable in superclass."); 7 => globalVariable; Assert(globalVariable == 7, "ScopeTest-7 assignement to global variable in extended class"); function int Test() { return GetV(); } function int GetVVirtual() { return v2; } function int GetglobalAndBaseclassVariable() { return globalAndBaseclassVariable; } } Base b; Assert(globalVariable == 2, "ScopeTest-2.1 constructor side-effects in global scope."); Super s; Assert(globalVariable == 7, "ScopeTest-7.1 superclass constructor side-effects in global scope."); 8 => b.v; Assert(b.v == b.GetV(),"ScopeTest-8 assigment to class-scope variable."); 9 => s.v; Assert(s.v == s.GetV(),"ScopeTest-9 assigment to base-class-scope variable."); 10 => s.v2; Assert(s.v == s.GetV(),"ScopeTest-10 assigment to super-class-scope variable."); Assert(s.v2 == 10,"ScopeTest-10.1 assigment to super-class-scope variable."); Assert(s.v2 == s.GetVVirtual(),"ScopeTest-10.1 virtual function resolution."); "110" => globalAndBaseclassVariable; 111 => s.globalAndBaseclassVariable; Assert(globalAndBaseclassVariable == "110","ScopeTest-11.1 aliased global and base-class variable."); Assert(s.GetglobalAndBaseclassVariable() == 111,"ScopeTest-11.2 aliased global and base-class variable."); Assert(s.globalAndBaseclassVariable() == 111,"ScopeTest-11.3 aliased global and base-class variable.");

2 1

Bug: Incorrect scanning of nested classes.
by Robin Davies 26 Sep '05

26 Sep '05

The following code : public class Instrument { class IInstrument { } } produces the following error. [t.ck]:line(25): class/type 'IInstrument' is already defined in namespace 'Instrument' The fix: ChuckScan.cpp line 1225: < ret = type_engine_scan0_class_def( env, body->section->class_def ); > ret = type_engine_scan1_class_def( env, body->section->class_def ); Rationale: The nested class has already had scan0 peformed during scan0 of the parent class. This call is made during scan1 processing, and should perform scan1 processing. Note that the other two cases in this switch perform scan1 processing, not scan0 processing. Please review the fix for correctness. I'm 98% sure it's correct. Regards, Robin Davies.

2 1