I think I've stumbled upon a 64 bit related bug somewhere in fftlib.c.
When I try to run vco2.orc and vco2.sco (see manual entry for vco2) on
my current CVS csound compiled for x86-64, it dies with a SIGSEGV.
GDB run log is below.

Starting program: /home/thomj/csound5/csound vco2.orc vco2.sco
---snip---
Csound version 5.00 beta (float samples) May 28 2005
0dBFS level = 32768.0
ftable 1:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182917932176 (LWP 10986)]
bfstages (ioptr=0xa966149c0, M=0, Utbl=0x1000000003, Ustride=16, 
NDiffU=2, StageCnt=4) at OOps/fftlib.c:1082
1082            w0r = *u0r;
(gdb) bt
#0  bfstages (ioptr=0xa966149c0, M=0, Utbl=0x1000000003, Ustride=16, 
NDiffU=2, StageCnt=4) at OOps/fftlib.c:1082
#1  0x000000000043e26b in fftrecurs (ioptr=0x64fb30, M=6625992, 
Utbl=0x65fb60, Ustride=931266560, NDiffU=13, StageCnt=6699872) at 
OOps/fftlib.c:1160
#2  0x0000000000440ea6 in rffts1 (ioptr=0x64fb30, M=13, Utbl=0x65fb60, 
BRLow=0x651ad8) at OOps/fftlib.c:2724
#3  0x0000002a9713ccde in vco2init (csound=0x5c2120, p=0x624ba8) at 
Opcodes/oscbnk.c:1816
#4  0x0000000000415ae1 in init0 (csound=0x5c2120) at Engine/insert.c:62
#5  0x000000000041d931 in oload (p=0x5c2120) at Engine/oload.c:751
#6  0x000000000041b056 in musmon (csound=0x5c2120) at Engine/musmon.c:198
#7  0x0000000000409389 in csoundCompile (csound_=0x11, argc=127, 
argv=0x5c2120) at Top/main.c:382
#8  0x000000000040404b in main (argc=3, argv=0x7fbffff868) at 
frontends/csound/csound_main.c:150
(gdb) print u0r
$1 = (float *) 0x40065fb60

The ftconv opcode crashes at the exact same place in bfstages, and both
opcodes use the RealFFT function.
I have compiled the very same csound tree on a 32 bit Linux box, and
it works perfectly there. However, I have no access to another 64 bit
computer, and can't see any obvious 64 bit traps in the fftlib.c code,
so can't verify if this is exclusively a 64 bit problem.
I haven't got time to debug this further now, but thought you'd like
to know.

Thom


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thom Johansen wrote:

> The ftconv opcode crashes at the exact same place in bfstages, and both
> opcodes use the RealFFT function.
> I have compiled the very same csound tree on a 32 bit Linux box, and
> it works perfectly there. However, I have no access to another 64 bit
> computer, and can't see any obvious 64 bit traps in the fftlib.c code,
> so can't verify if this is exclusively a 64 bit problem.
> I haven't got time to debug this further now, but thought you'd like
> to know.

What is printed before the crash with the attached patch applied ?
Also, does it still crash after a clean recompile with -O0 ?

I too run Csound on a 64bit machine;  will look
==John ffitch


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Istvan Varga wrote:
> What is printed before the crash with the attached patch applied ?
> Also, does it still crash after a clean recompile with -O0 ?

The following is output:

POW2: m = 14, result = 16384
POW2: m = 14, result = 16384
POW2: m = 6, result = 64
POW2: m = 6, result = 64
POW2: m = 5, result = 32
POW2: m = 5, result = 32
POW2: m = 8, result = 256
POW2: m = 13, result = 8192
POW2: m = 5, result = 32
POW2: m = 13, result = 8192
POW2: m = 7, result = 128
POW2: m = 7, result = 128
POW2: m = 10, result = 1024
bfstages: ioptr = 0x64f1b0, M = 10, Utbl = 0x65f1e0
           Ustride = 16, NDiffU = 2, StageCnt = 3
POW2: m = 10, result = 1024
POW2: m = 10, result = 1024
POW2: m = 8, result = 256

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182919965120 (LWP 11129)]
bfstages (ioptr=0xa00440d41, M=0, Utbl=0x1000000002, Ustride=3, 
NDiffU=16, StageCnt=17) at OOps/fftlib.c:1090
1090            w0r = *u0r;
(gdb) bt
#0  bfstages (ioptr=0xa00440d41, M=0, Utbl=0x1000000002, Ustride=3, 
NDiffU=16, StageCnt=17) at OOps/fftlib.c:1090
#1  0x00000000004408b0 in fftrecurs (ioptr=0x64f1b0, M=2, Utbl=0x65f1e0, 
Ustride=1024, NDiffU=3, StageCnt=6697440) at OOps/fftlib.c:43
#2  0x0000000000444c44 in csoundRealFFT (csound=0x5c2120, buf=0x10, 
FFTsize=4) at OOps/fftlib.c:2726
#3  0x0000002a97337f67 in vco2init (csound=0x5c2120, p=0x624228) at 
Opcodes/oscbnk.c:1815
#4  0x000000000041a069 in init0 (csound=0x5c2120) at Engine/insert.c:62
#5  0x000000000041e9b1 in oload (p=0x5c2120) at Engine/oload.c:751
#6  0x000000000041b9bd in musmon (csound=0x5c2120) at Engine/musmon.c:198
#7  0x000000000040947c in csoundCompile (csound_=0x651148, argc=127, 
argv=0x5c2120) at Top/main.c:382
#8  0x0000000000403fa5 in main (argc=0, argv=0x300000001) at 
frontends/csound/csound_main.c:150

I find it strange that the M value parameters are suddenly reported
differently by GDB.
And yes, it crashes in the same spot without optimisations.
I have also tried compiling with both gcc 3.3 and 3.4, since it
looked a bit like a compiler bug, but the outcome is the same.
You should probably wait until John ffitch or someone else tries
it as well before you invest too much time in this.

Thom


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I have just tried the test/vco.{orc,sco} on 64bit Csound5 and it ran
without any problems.  One thought though; are you using floats or
doubles?  I am using doubles for MYFLT.

I did wonder about mismatches of pointer types, but did not see any.

I did not like

bfstages: ioptr = 0x64f1b0, M = 10, Utbl = 0x65f1e0
           Ustride = 16, NDiffU = 2, StageCnt = 3

as ioptr and Utbl should be a 64bit pointer; or are you compiled in
32bit mode?   Looks like it but gdb is printing 64bit pointers.

==John ffitch



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thom Johansen wrote:

> The following is output:
> [...]
> bfstages: ioptr = 0x64f1b0, M = 10, Utbl = 0x65f1e0
>           Ustride = 16, NDiffU = 2, StageCnt = 3

These all look normal, I get the exact same POW2 values, and bfstages
is also similar (with the obvious exception of the pointer values):

bfstages: ioptr = 0x814d808, M = 10, Utbl = 0x815d828
           Ustride = 16, NDiffU = 2, StageCnt = 3

The only difference is that I do not get the crash (on a 32 bit machine).
It is also apparent now that the crash occurs on the first call to
bfstages.

> 1090            w0r = *u0r;

u0r is a pointer to a precalculated cosine table (as passed in Utbl).
It would have been interesting to see the pointer value (and comparing to
Utbl above) at the time of the crash. The pointer is either out of range
or the table somehow was not allocated correctly.


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

jpff@codemist.co.uk wrote:

> I did wonder about mismatches of pointer types, but did not see any.

Those would most probably result in compiler warnings. Also, all floating
point data is exclusively MYFLT (you can grep for \ and \
and find nothing). The 'long' type is not used at all, and I did not (yet)
find code that attempts to cast a pointer to an 'int' (that would be an
obvious bug on a 64 bit machine). There are no declarations and prototypes
(which could possibly mismatch) of any external variables or functions.
Knowing all these, and the fact that you did not get the crash on another
64 bit system, this issue is becoming really strange.



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

jpff@codemist.co.uk wrote:
> I have just tried the test/vco.{orc,sco} on 64bit Csound5 and it ran
> without any problems.

This is a typo, and you ran vco2.orc/sco and not vco.orc/sco, yes?

> One thought though; are you using floats or
> doubles?  I am using doubles for MYFLT.
> 
> I did wonder about mismatches of pointer types, but did not see any.
> 
> I did not like
> 
> bfstages: ioptr = 0x64f1b0, M = 10, Utbl = 0x65f1e0
>            Ustride = 16, NDiffU = 2, StageCnt = 3
> 
> as ioptr and Utbl should be a 64bit pointer; or are you compiled in
> 32bit mode?   Looks like it but gdb is printing 64bit pointers.
> 
> ==John ffitch

I'm using floats, and am compiling in 64 bit mode. Fails just as
miserably with double samples. As for those pointers, it's more than
likely the address just happens to fit in the lower 32 bits.

Thom


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Istvan Varga wrote:
>> bfstages: ioptr = 0x64f1b0, M = 10, Utbl = 0x65f1e0
>>           Ustride = 16, NDiffU = 2, StageCnt = 3
> 
> 
> These all look normal, I get the exact same POW2 values, and bfstages
> is also similar (with the obvious exception of the pointer values):
> 
> bfstages: ioptr = 0x814d808, M = 10, Utbl = 0x815d828
>           Ustride = 16, NDiffU = 2, StageCnt = 3
> 
> The only difference is that I do not get the crash (on a 32 bit machine).
> It is also apparent now that the crash occurs on the first call to
> bfstages.
> 
>> 1090            w0r = *u0r;
> 
> 
> u0r is a pointer to a precalculated cosine table (as passed in Utbl).
> It would have been interesting to see the pointer value (and comparing to
> Utbl above) at the time of the crash. The pointer is either out of range
> or the table somehow was not allocated correctly.

It very soon became apparent that the GDB is broken on my platform,
so I've stopped using it for this problem, however, a couple of
trusty old fprintfs should do the job.
I added a fprintf just before the u0r access in question and got
the following output:

[...]
POW2: m = 10, result = 1024
POW2: m = 10, result = 1024
POW2: m = 8, result = 256
Uinc = 1024, Uinc4 = 4096, u0r = 0x664b70, Utbl = 0x660b70
Uinc = 1024, Uinc4 = -4096, u0r = 0x400660b70, Utbl = 0x660b70
Csound tidy up: Segmentation fault

So contrary to what GDB claims, u0r actually does get assigned 
correctly, but gets clobbered pretty badly somewhere. I tracked
the problem down to the area around line 1058:

if ((int) DiffUCnt == NDiffU / 2)
   Uinc4 = -Uinc4;
u0r += Uinc4;

After studying the disassembly, it became apparent that GCC didn't
sign extend the 32 bit int Uinc4 before adding it to the 64 bit
address, so the upper 32 bits of the register Uinc4 is placed in
contains old data.
After replacing all the ints in bfstages with longs, which are 64 bits
wide, the same problem appeared in ibfstages. After doing the same
there, everything started working perfectly.
However, I believe adding ints to a pointer should work regardless
of size, so this probably is a bug in GCC (or perhaps just the ones
bundled with Ubuntu, which is the distro I'm using).

Thom


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thom Johansen wrote:

> if ((int) DiffUCnt == NDiffU / 2)
>   Uinc4 = -Uinc4;
> u0r += Uinc4;
> 
> After studying the disassembly, it became apparent that GCC didn't
> sign extend the 32 bit int Uinc4 before adding it to the 64 bit
> address, so the upper 32 bits of the register Uinc4 is placed in
> contains old data.

And it actually should not sign extend (as Uinc* were unsigned ints),
so the bug is really in the code, and not in GCC. Thanks for finding
this, I have changed all Uinc* variables from unsigned int to int,
and committed the changes. Should probably work now.


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Istvan Varga wrote:
> And it actually should not sign extend (as Uinc* were unsigned ints),
> so the bug is really in the code, and not in GCC. Thanks for finding
> this, I have changed all Uinc* variables from unsigned int to int,
> and committed the changes. Should probably work now.

Should have spotted that one myself ;)
Checked out a fresh copy of fftlib.c, and it works just fine now,
thanks for fixing.

Thom


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net