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

[patch] Some c++-isms and dont segfault on FreeBSD
by Rasmus Kaj 20 Nov '05

20 Nov '05

Hi ChucKers! I'm back at trying to use ChucK on FreeBSD. I use the current cvs head version (in chuck_dev/v2) and, after marginal Linux -> FreeBSD changes to makefile.oss, it works! When doing "chuck_autotest [0-9]*.ck" in the tests catalogue, some of the tests fail, but that seems to be mainly because some stuff that run infinite loops isn't marked as fail-correct. However, I'd like to use g++ for compiling the c++ stuff, and don't link with -lstdc++ explicitly. So I change that in makefile.oss, and get a segmentation fault when trying to run. Taking care of some of the -Wall warnings, mainly having a virtual destructor for classes that have virtual methods (so the correct destructor will be called when deleting a base-class pointer) and constructor using initialisers for Chuck_DLL, and using string::size_type for string index variables (in two places), it seems fine again (the same tests as before fails). So, the patch is in http://people.kth.se/~kaj/tmp/chuck/ (along with a test log). If this is useful, I could do more initialisation in constructors and a few other c++-ism fixes that might save a few clock cycles here and there and submit more patches ... Ok? -- Rasmus Kaj --+-- rasmus(a)kaj.se --+-- http://www.stacken.kth.se/~kaj/ Deja Moo: The feeling that you've heard this bullshit before

2 1

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