-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Apr 27, 2007 at 06:00:10PM +0200, Michel Koppelaar wrote:

Hi,

I seem to be having the same problem. I've been trying to get ChucK to run on AMD64/Linux these last few days. Tried alsa, oss and jack build options: segfaults in each case. More details:

================================================================================= 1. platform distro: Ubuntu 7.04 cpu: AMD Athlon 64 X2 Dual Core Processor 4200+

2. chuck --version chuck version: 1.2.0.8 (dracula) exe target: linux (alsa) http://chuck.cs.princeton.edu/

3. gdb output GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -v5 ../examples/stk/bowed.ck Starting program: /home/michel/src/chuck-1.2.0.8/src/chuck -v5 ../examples/stk/bowed.ck [Thread debugging using libthread_db enabled] [New Thread 47062529307568 (LWP 12822)] [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 1082132800 (LWP 12825)] [chuck]:(3:SEVERE): | | class 'math'... [chuck]:(3:SEVERE): | | class 'opsc'... [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]:(5:INFORM): | | starting kb loop... [New Thread 1090525504 (LWP 12826)] [chuck]:(3:SEVERE): | allocating buffers for 512 x 2 samples... [chuck]:(3:SEVERE): starting compilation... [chuck]:(2:SYSTEM): starting listener on port: 8888... [New Thread 1098918208 (LWP 12827)] [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 47062529307568 (LWP 12822)] 0x0000000000491420 in Instrmnt_ctor () =================================================================================

Hopefully this can be sorted out. I'm really interested in trying out ChucK.

Hmm, I dug around a bit, not really knowing what I'm doing, but I suspect that the culprit is probably an assumption about the size of UINTS... a 32-bit vs 64-bit issue. My eye was drawn to that OBJ_MEMBER_UINT() macro, and I took a shimmering journey into the through-the-looking-glass world of defines on top of defines on top of defines: #define OBJ_MEMBER_UINT(obj,offset) (*(t_CKUINT *)OBJ_MEMBER_DATA(obj,offset)) ... #define t_CKUINT t_CKDWORD ... #define t_CKDWORD unsigned long There's also this: #define OBJ_MEMBER_DATA(obj,offset) (obj->data + offset) So, if offset just happens to be a 32-bit value, that smells to me like a likely source of a segfault. Offset probably needs to be a long long, doesn't it? But, again, there is probably advanced casting mojo going on, and my knowlege of Intel assembler is near zero. It's also been over 4 years since I last wrote a line of C. I hope there are devs reading this list. If I can do anything more to help, I will gladly do so. - -ken -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFGMjxue8HF+6xeOIcRAnvRAJ9+75gQtbxEDxX5i2lbz84b1TLDzwCg9YGD rQdqQCWKuNGT3EpQgrh+k9A= =3sxO -----END PGP SIGNATURE-----

On Sat, 28 Apr 2007 10:55:30 -0700 Ken Restivo wrote: *snip*

I asked a friend who does a lot of C++ work to take a brief look at this.

He shook his head sadly at the use of macros instead of inline functions, the use of casts to obliterate type safety, of #define's instead of typedefs, and the obscuring of the likelihood that ->data is a struct. He said, basically, this is C, not C++, regardless of what the file extension says. I poked around some more and it looks like a lot of the Ugen code was lifted from another, older project-- maybe that was C code?

I took a look myself. I had to use gcc -E to see what on earth all those #define's are doing! It does look like a pointer size issue, but it would take me too much time to try and understand the source. I know C, but no C++.

He also didn't hold out much hope that any of its developers would show any interest in fixing this stuff either. The OBJ_MEMBER_UINT's are all over the filter, osc, xxx(?!), and stk ugens, as well as the Std lib. The obj->data stuff is in chuck_instr.cpp but nowhere else. But it's hard to tell how much stuff like this is lurking elsewhere in the code.

I'd be willing to do the gruntwork of search-and-replacing code, if someone who knows what they're doing wants to tell me pretty much exactly what to do. If nobody jumps up to do that over the next day or two, it'd probably be a better use of time to start learning CSound instead, and maybe have another look at ChucK in a few years if anyone gets it 64-bit safe by then.

Ironically, I got interested in ChucK because CSound seemed a very kludgy way to do audio programming. - Oh well, there's always SuperCollider ;) Michel

On Sat, 28 Apr 2007 16:20:24 -0400 (EDT) Ge Wang wrote: *snip*

The question is this: is it possible to compile ChucK under 64-bit linux in a 32-bit mode? (We don't know this answer to this one).

It's probably not impossible since most distros have tools for running programs in 32-bit mode. What makes this option non-trivial, however, is the fact that all libraries that you depend on must also be around in a 32-bit incarnation. So, for instance, you need a 32-bit libsndfile, which needs a 32-bit libFLAC... Ubuntu does a fair job at 32-bit compatibility, but simply adding the -m32 compiler flag does not get me a 32-bit ChucK. Many people seem to be using chrooted 32-bit environments though - this might work. I might look into this option when I get some more time. Michel

Greetings again,

...

I asked a friend who does a lot of C++ work to take a brief look at this.

He shook his head sadly at the use of macros instead of inline functions, the use of casts to obliterate type safety, of #define's instead of typedefs, and the obscuring of the likelihood that ->data is a struct. He said, basically, this is C, not C++, regardless of what the file extension says. I poked around some more and it looks like a lot of the Ugen code was lifted from another, older project-- maybe that was C code?

These are fair criticisms in general, but sometimes we do have our own reasons for implementing things the way we do. In other instances, we probably should adopt better practices. In the end, it's just how our warped minds work. Our goal isn't necessarily to make C++ happy, but rather to make ChucK users happy (and fitter, and more productive).

...

I'd be willing to do the gruntwork of search-and-replacing code, if someone who knows what they're doing wants to tell me pretty much exactly what to do. If nobody jumps up to do that over the next day or two, it'd probably be a better use of time to start learning CSound instead, and maybe have another look at ChucK in a few years if anyone gets it 64-bit safe by then.

I think it's gonna take a system-wide evaluation/fixing/testing to make things robustly 64-bit. Until then it's hard to say what needs to be done. We are fully planning to do that at some future point. For now, is it possible to compile ChucK in 32-bit mode under linux (similar to the 64-bit Apple G5)?

Ironically, I got interested in ChucK because CSound seemed a very kludgy way to do audio programming. - Oh well, there's always SuperCollider ;)

We think it's a good idea to learn as many languages as possible. Different tools tailored for different tasks! Best, Ge!

Not sure about linux, but I know that for darwin linking of 32 bit binaries to 64 bit binaries is impossible. In the best case, you will have to do all sorts of tricks at the kernel level to allow 64 bit code (with pointers possibly way way up in the address space) to run in 32 bit mode. Your particular seg-fault issue may be related to an invalid alignment problem. If your OBJ_MEMBER_DATA macro evaluates to a value that isn't a multiple of the unsigned long size (8 bytes), then OBJ_MEMBER_UINT could effectively be causing an invalid instruction to be generated. You could add a check to make sure that the value OBJ_MEMBER_DATA returns in OBJ_MEMBER_UINT is a multiple of 8. _Mark On Apr 28, 2007, at 3:48 PM, Ken Restivo wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Sat, Apr 28, 2007 at 05:06:29PM -0400, Ge Wang wrote:

...

...

...

...

data is a struct. He said, basically, this is C, not C++, regardless of what

He shook his head sadly at the use of macros instead of inline functions, the use of casts to obliterate type safety, of #define's instead of typedefs, and the obscuring of the likelihood that - the file extension says. I poked around some more and it looks like a lot of the Ugen code was lifted from another, older project-- maybe that was C code?

These are fair criticisms in general, but sometimes we do have our own reasons for implementing things the way we do. In other instances, we probably should adopt better practices. In the end, it's just how our warped minds work. Our goal isn't necessarily to make C++ happy, but rather to make ChucK users happy (and fitter, and more productive).

No prob. Love the Radiohead reference too. And thanks for taking the time to reply, amidst preparing for your oral dissertation defense.

...

...

...

I'd be willing to do the gruntwork of search-and-replacing code, if someone who knows what they're doing wants to tell me pretty much exactly what to do. If nobody jumps up to do that over the next day or two, it'd probably be a better use of time to start learning CSound instead, and maybe have another look at ChucK in a few years if anyone gets it 64-bit safe by then.

I think it's gonna take a system-wide evaluation/fixing/testing to make things robustly 64-bit. Until then it's hard to say what needs to be done. We are fully planning to do that at some future point. For now, is it possible to compile ChucK in 32-bit mode under linux (similar to the 64-bit Apple G5)?

That was the first thing I tried, last week: compiling with -m32. Everything compiled, but the final link step failed, because it was apparently trying to link to the 32-bit versions of the JACK libraries, which obviously don't and can't exist on this system. Maybe there's some way to convince GCC to link a bunch of 32- bit .o's to 64-bit libraries?

...

...

Ironically, I got interested in ChucK because CSound seemed a very kludgy way to do audio programming. - Oh well, there's always SuperCollider ;)

We think it's a good idea to learn as many languages as possible. Different tools tailored for different tasks!

And, for what I'm doing, I find ChucK a far more natural and user- friendly language. So, I'll spend some time trying to get it running.

- -ken -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFGM89Me8HF+6xeOIcRAlBfAKDXqXtJ1VoImwgGFtaBIi9HLSi2qgCeMGdT EorX3o9C+iQqZmzQYtKAhNM= =KhYk -----END PGP SIGNATURE----- _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

#define OBJ_MEMBER_UINT(obj,offset) (*(t_CKUINT *)OBJ_MEMBER_DATA(obj,offset)) ... #define t_CKUINT t_CKDWORD ... #define t_CKDWORD unsigned long

There's also this: #define OBJ_MEMBER_DATA(obj,offset) (obj->data + offset)

On Fri, Apr 27, 2007 at 06:00:10PM +0200, Michel Koppelaar wrote:

...

Hi,

I seem to be having the same problem. I've been trying to get ChucK to run on AMD64/Linux these last few days. Tried alsa, oss and jack build options: segfaults in each case. More details: <snip>

Hopefully this can be sorted out. I'm really interested in trying out ChucK.

Hmm, I dug around a bit, not really knowing what I'm doing, but I suspect that the culprit is probably an assumption about the size of UINTS... a 32-bit vs 64-bit issue. My eye was drawn to that OBJ_MEMBER_UINT() macro, and I took a shimmering journey into the

Speaking as a professional C++ programmer.... 1) In defense of Ge, few of us get the opportunity to work on code that doesn't have legacy. Even when we do, few of us manage to produce code that ages well, in retrospect. 2) 32 to 64 bit ports are non-trivial. 3) The analysis given is incorrect. The code in question is fine, as long as none of your classes exceed 16GB in size. Whatever the problem is, it's not in the cited code. 4) Although C++ inline functions are preferrable to macros, sylistically speaking, the functionally equivalent C++ inline functions are not, in fact, any safer than the macros in this case. In this particular case, I believe your friend is right. The code in question would not be rewritten because there's not actually a compelling improvement that can be made at this point. Robin Davies Lead Software Developer Quest Web Reports Quest Software 613.270.1569 Identity Management for the Windows Enterprise: See how Quest helps you leverage your existing investment to solve the identity management challenge! -----Original Message----- From: chuck-users-bounces@lists.cs.princeton.edu [mailto:chuck-users-bounces@lists.cs.princeton.edu] On Behalf Of Ken Restivo Sent: Saturday, April 28, 2007 1:56 PM To: ChucK Users Mailing List Subject: Re: [chuck-users] Anyone else running ChucK dual-core in 64-bitmode? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Apr 27, 2007 at 11:09:50AM -0700, Ken Restivo wrote: through-the-looking-glass world of defines on top of defines on top of defines:

#define OBJ_MEMBER_UINT(obj,offset) (*(t_CKUINT

... #define t_CKUINT t_CKDWORD ... #define t_CKDWORD unsigned long

There's also this: #define OBJ_MEMBER_DATA(obj,offset) (obj->data + offset)

So, if offset just happens to be a 32-bit value, that smells to me

*)OBJ_MEMBER_DATA(obj,offset)) like a likely source of a segfault. Offset probably needs to be a long long, doesn't it?

I asked a friend who does a lot of C++ work to take a brief look at this. He shook his head sadly at the use of macros instead of inline functions, the use of casts to obliterate type safety, of #define's instead of typedefs, and the obscuring of the likelihood that ->data is a struct. He said, basically, this is C, not C++, regardless of what the file extension says. I poked around some more and it looks like a lot of the Ugen code was lifted from another, older project-- maybe that was C code? He also didn't hold out much hope that any of its developers would show any interest in fixing this stuff either. The OBJ_MEMBER_UINT's are all over the filter, osc, xxx(?!), and stk ugens, as well as the Std lib. The obj->data stuff is in chuck_instr.cpp but nowhere else. But it's hard to tell how much stuff like this is lurking elsewhere in the code. I'd be willing to do the gruntwork of search-and-replacing code, if someone who knows what they're doing wants to tell me pretty much exactly what to do. If nobody jumps up to do that over the next day or two, it'd probably be a better use of time to start learning CSound instead, and maybe have another look at ChucK in a few years if anyone gets it 64-bit safe by then. - -ken -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD4DBQFGM4qSe8HF+6xeOIcRAllFAJ9VjIJ8C1UYwQZKeqYragR9CE2UIwCVEhRC xcHaCfclv2oU2g0ermIGsw== =mpph -----END PGP SIGNATURE----- _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users