[chuck-users] chuck segfaults at startup on core2duo on linux jack
Ken Restivo
ken at restivo.org
Thu Apr 26 02:28:03 EDT 2007
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
OK, here it is:
(gdb) run -v5 cw.ck
[Thread debugging using libthread_db enabled]
[New Thread 47270109016944 (LWP 3931)]
[chuck]:(2:SYSTEM): setting log level to: 5 (INFORM)...
[chuck]:(2:SYSTEM): initializing virtual machine...
[chuck]:(2:SYSTEM): | behavior: HALT
[chuck]:(2:SYSTEM): | allocating shreduler...
[chuck]:(2:SYSTEM): | allocating messaging buffers...
[chuck]:(2:SYSTEM): | real-time audio: YES
[chuck]:(2:SYSTEM): | mode: CALLBACK
[chuck]:(2:SYSTEM): | sample rate: 48000
[chuck]:(2:SYSTEM): | buffer size: 512
[chuck]:(2:SYSTEM): | num buffers: 8
[chuck]:(2:SYSTEM): | devices adc: 0 dac: 0 (default 0)
[chuck]:(2:SYSTEM): | channels in: 2 out: 2
[chuck]:(2:SYSTEM): initializing compiler...
[chuck]:(3:SEVERE): | initializing type checker...
[chuck]:(3:SEVERE): | | adding base classes...
[chuck]:(3:SEVERE): | | | class 'object'
[chuck]:(3:SEVERE): | | | class 'array'
[chuck]:(3:SEVERE): | | | class 'string'
[chuck]:(3:SEVERE): | | | class 'ugen'
[chuck]:(3:SEVERE): | | | class 'shred'
[chuck]:(3:SEVERE): | | | class 'event'
[chuck]:(3:SEVERE): | | | class 'class'
[chuck]:(3:SEVERE): | initializing emitter...
[chuck]:(3:SEVERE): | loading built-in modules...
[chuck]:(3:SEVERE): | | module osc...
[chuck]:(3:SEVERE): | | module xxx...
[chuck]:(3:SEVERE): | | module filter...
[chuck]:(3:SEVERE): | | module STK...
[chuck]:(3:SEVERE): | | class 'machine'...
[chuck]:(3:SEVERE): | | class 'std'...
[chuck]:(5:INFORM): | | initializing KBHitManager...
[New Thread 1082132832 (LWP 3939)]
[chuck]:(3:SEVERE): | | class 'math'...
[chuck]:(3:SEVERE): | | class 'opsc'...
[chuck]:(5:INFORM): | | starting kb loop...
[chuck]:(2:SYSTEM): type dependency resolution: MANUAL
[chuck]:(2:SYSTEM): initializing synthesis engine...
[chuck]:(3:SEVERE): | initializing 'dac'...
[chuck]:(3:SEVERE): | initializing 'adc'...
[chuck]:(3:SEVERE): | initializing 'blackhole'...
[chuck]:(2:SYSTEM): | initializing 'real-time' audio...
[chuck]:(5:INFORM): | | initializing callback...
[chuck]:(3:SEVERE): | | new buffer size: 512 -> 1024
[chuck]:(3:SEVERE): | allocating buffers for 1024 x 2 samples...
[chuck]:(3:SEVERE): starting compilation...
[chuck]:(2:SYSTEM): starting listener on port: 8888...
[New Thread 1090525536 (LWP 3940)]
[chuck]:(2:SYSTEM): running virtual machine...
[chuck]:(3:SEVERE): | initializing audio buffers...
[chuck]:(3:SEVERE): | virtual machine running...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47270109016944 (LWP 3931)]
0x00000000004820d5 in osc_ctor ()
(gdb) bt
#0 0x00000000004820d5 in osc_ctor ()
#1 0x000000000041750e in Chuck_Instr_Func_Call_Member::execute ()
#2 0x0000000000412195 in Chuck_VM::compute ()
#3 0x00000000004123dc in Chuck_VM::run ()
#4 0x000000000045a1a5 in main ()
(gdb) info frame
Stack level 0, frame at 0x7fff318d1fb0:
rip = 0x4820d5 in osc_ctor; saved rip 0x41750e
called by frame at 0x7fff318d1ff0
Arglist at 0x7fff318d1f70, args:
Locals at 0x7fff318d1f70, Previous frame's sp is 0x7fff318d1fb0
Saved registers:
rbx at 0x7fff318d1f98, rbp at 0x7fff318d1fa0, rip at 0x7fff318d1fa8
So the constructor is dying. It's been years since I last messed with gdb, but I suppose I could dig around more, or step through the source a bit, but I'm not quite sure what to look for in this case.
The cw.ck file is very simple. It is just this:
// Shamefully written by Stefan Petersen, spe (at) stacken (dot) kth (dot) se
// No copyright, no copyleft, no guarantees, no protection, no seat belt
// just a crash test dummy.
// Generates a telegraphy signal with proper spacing of ditts, dahs and
// between letters. But the information is completely random
SinOsc s => Gain g => dac;
Std.rand2f(600.0, 1500.0) => float tone;
Std.rand2(50,100) => int ditt;
while (true) {
tone => s.freq;
if (Std.randf() > 0.0) {
ditt::ms => now;
} else {
(3*ditt)::ms => now;
}
0.0 => s.freq;
ditt::ms => now;
if (Std.randf() > 0.25) {
(2*ditt)::ms => now;
}
}
It's basically sample code, it appears. And, it works flawlessly on my 32-bit Core 1 Duo machine. FYI, all of the chuck examples also SIGSEGV too. For example, the basic/blit.ck file dies in the Blit_ctor(), etc etc.
- -ken
- -------------
On Wed, Apr 18, 2007 at 02:48:15PM -0400, Spencer Salazar wrote:
> Hey Ken,
> Yikes, sorry to hear that. Could you provide a stack trace of this?
> That would be most helpful in figursing out the problem. Im not sure
> if you're handy with gdb, but the easiest way to do it is like this:
>
> $ gdb chuck
> (gdb) run -v5 cw.ck
> ... (crash happens) ...
> (gdb) backtrace
> ... (stack trace printed here) ...
>
> Copying all of the output of that gdb session (including the chuck
> log output) will be very helpful as that typically specifies exactly
> where the crash is occurring.
>
> It would also be helpful if you could provide the text of cw.ck, if
> you don't mind. It can be assumed that cw.ck doesn't crash ChucK on
> other machines, correct?
>
> spencer
>
> On Apr 18, 2007, at 1:49 AM, Ken Restivo wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Alas, I am dead in the ChucK waters.
> >
> > Just got a new Core 2 Duo laptop. Built ChucK 1.2.0.8 for linux-
> > jack. Planned to use this machine for ChucK experimentation and
> > live performance.
> >
> > And then:
> >
> > $ chuck cw.ck
> > Segmentation fault
> >
> > Gah!
> >
> > $ chuck --probe
> > [chuck]: found 1 device(s) ...
> > [chuck]: ------( chuck -- dac1 )---------------
> > [chuck]: device name = "Jack Server"
> > [chuck]: probe [success] ...
> > [chuck]: # output channels = 2
> > [chuck]: # input channels = 2
> > [chuck]: # duplex Channels = 2
> > [chuck]: default device = YES
> > [chuck]: natively supported data formats:
> > [chuck]: 32-bit float
> > [chuck]: supported sample rates:
> > [chuck]: 48000 Hz
> > [chuck]:
> > [chuck]: ------( chuck -- 3 MIDI inputs )------
> > [chuck]: [0] : "Midi Through Port-0"Segmentation fault
> >
> >
> > Sad. No ChucK for me! This is with the stock 1.2.0.8
> >
> > - -ken
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.1 (GNU/Linux)
> >
> > iD8DBQFGJbF8e8HF+6xeOIcRAllLAKD0f78S+IOEEFqJIGcASfthaIX5mACghGW1
> > qb6fSvK2uBex703V7MQKri8=
> > =kaw9
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > chuck-users mailing list
> > chuck-users at lists.cs.princeton.edu
> > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFGMEZze8HF+6xeOIcRAvMyAKDUZuBNy123cVAI/YdAjUnkSGYwLgCeIEzk
zvQmFDPS47ShoRsQkuhlQNM=
=dAg9
-----END PGP SIGNATURE-----
More information about the chuck-users
mailing list