chuck segfaults at startup on core2duo on linux jack
-----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-----
Hey Ken, Yikes, sorry to hear that. Could you provide a stack trace of this? That would be most helpful in figuring 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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-----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@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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFGMEZze8HF+6xeOIcRAvMyAKDUZuBNy123cVAI/YdAjUnkSGYwLgCeIEzk zvQmFDPS47ShoRsQkuhlQNM= =dAg9 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
My old C debugging memories are slowly returning.
I recompiled with CHUCK_DEBUG, and still, this looks really bad:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47625308423024 (LWP 27946)]
0x00000000004b2d8d in osc_ctor (SELF=0x0, ARGS=0x9591a8, SHRED=0x9588d0) at ugen_osc.cpp:249
249 OBJ_MEMBER_UINT(SELF, osc_offset_data) = (t_CKUINT)d;
(gdb) bt
#0 0x00000000004b2d8d in osc_ctor (SELF=0x0, ARGS=0x9591a8, SHRED=0x9588d0) at ugen_osc.cpp:249
#1 0x0000000000421200 in Chuck_Instr_Func_Call_Member::execute (this=0x76a050, vm=0x76d770, shred=0x9588d0)
at chuck_instr.cpp:2651
#2 0x000000000042aebb in call_pre_constructor (vm=0x76d770, shred=0x9588d0, pre_ctor=0x793610, stack_offset=0)
at chuck_instr.cpp:2070
#3 0x000000000042138f in Chuck_Instr_Pre_Constructor::execute (this=0x958090, vm=0x76d770, shred=0x9588d0)
at chuck_instr.cpp:2084
#4 0x000000000040faac in Chuck_VM_Shred::run (this=0x9588d0, vm=0x76d770) at chuck_vm.cpp:1426
#5 0x0000000000413bd2 in Chuck_VM::compute (this=0x76d770) at chuck_vm.cpp:608
#6 0x0000000000413f43 in Chuck_VM::run (this=0x76d770) at chuck_vm.cpp:555
#7 0x00000000004776ca in main (argc=3, argv=0x7fff0a0b9668) at chuck_main.cpp:702
(gdb) list
244 CK_DLL_CTOR( osc_ctor )
245 {
246 Osc_Data * d = new Osc_Data;
247 Chuck_DL_Return r;
248 // return data to be used later
249 OBJ_MEMBER_UINT(SELF, osc_offset_data) = (t_CKUINT)d;
250 osc_ctrl_freq( SELF, &(d->freq), &r, SHRED );
251 }
252
253
(gdb) info local
d = (Osc_Data *) 0x8d0570
r = {
v_int = 0,
v_uint = 0,
v_float = 0,
v_dur = 0,
v_time = 0,
v_object = 0x0,
v_string = 0x0
}
... which comes from ...
(gdb) up
#1 0x0000000000421200 in Chuck_Instr_Func_Call_Member::execute (this=0x76a050, vm=0x76d770, shred=0x9588d0)
at chuck_instr.cpp:2651
2651 f( (Chuck_Object *)(*mem_sp), mem_sp + 1, shred );
(gdb) list
2646 if( func->native_func_type == Chuck_VM_Code::NATIVE_CTOR )
2647 {
2648 // cast to right type
2649 f_ctor f = (f_ctor)func->native_func;
2650 // call
2651 f( (Chuck_Object *)(*mem_sp), mem_sp + 1, shred );
2652 }
2653 else
2654 {
2655 // cast to right type
(gdb) info locals
f = (f_ctor) 0x4b2d52
Hey Ken, Yikes, sorry to hear that. Could you provide a stack trace of this? That would be most helpful in figuring 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@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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFGMbY6e8HF+6xeOIcRAlqEAJ4khbJWq9i2U8KRWAZxpTlOen80IgCgmBrP h/2AQ122UOvkoIvsFxOwMDo= =GGPa -----END PGP SIGNATURE-----
participants (2)
-
Ken Restivo -
Spencer Salazar