extace crashed with SIGSEGV in fftw_execute()

[Dana Goyette]

Binary package hint: extace

Using PulseAudio, of course; distro is Karmic.
Just attempting to open the voiceprint app "extace" results in it segfaulting. gdb gives this:

(gdb) r
Starting program: /usr/bin/extace
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffeee18950 (LWP 9484)]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff66d4f33 in fftw_execute (p=0x0) at execute.c:24
24 execute.c: No such file or directory.
 in execute.c
(gdb) thread apply all bt

Thread 2 (Thread 0x7fffeee18950 (LWP 9484)):
#0 0x00007ffff5f39686 in *__GI___poll (fds=0x7fffeee18080, nfds=1,
    timeout=100) at ../sysdeps/unix/sysv/linux/poll.c:87
#1 0x000000000040c997 in input_reader_thread ()
#2 0x00007ffff61d63ba in start_thread () from /lib/libpthread.so.0
#3 0x00007ffff5f431bd in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#4 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7ffff7fc5760 (LWP 9481)):
#0 0x00007ffff66d4f33 in fftw_execute (p=0x0) at execute.c:24
#1 0x000000000040d7a1 in run_fft ()
#2 0x000000000040d8b7 in input_chewer ()
#3 0x0000000000408d65 in draw ()
#4 0x00007ffff692d10b in g_timeout_dispatch (source=0x9ed520,
    callback=0x2b110, user_data=0x0)
    at /build/buildd/glib2.0-2.21.3/glib/gmain.c:3396
#5 0x00007ffff692c9fe in g_main_dispatch (context=0x73c140)
    at /build/buildd/glib2.0-2.21.3/glib/gmain.c:1960
#6 IA__g_main_context_dispatch (context=0x73c140)
    at /build/buildd/glib2.0-2.21.3/glib/gmain.c:2513
#7 0x00007ffff69303c8 in g_main_context_iterate (context=0x73c140,
---Type <return> to continue, or q <return> to quit---
    block=<value optimized out>, dispatch=<value optimized out>,
    self=<value optimized out>)
    at /build/buildd/glib2.0-2.21.3/glib/gmain.c:2591
#8 0x00007ffff6930825 in IA__g_main_loop_run (loop=0x9ed640)
    at /build/buildd/glib2.0-2.21.3/glib/gmain.c:2799
#9 0x00007ffff78de377 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#10 0x00000000004105ac in main ()

ProblemType: Crash
Architecture: amd64
CrashCounter: 1
Date: Tue Jul 14 19:36:34 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/extace
NonfreeKernelModules: windrvr6 fglrx
Package: extace 1.9.9-6
ProcCmdline: extace
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-3.18-generic
SegvAnalysis:
 Segfault happened at: 0x7f4e2f680f33 <fftw_execute+3>: mov (%rdi),%rdi
 PC (0x7f4e2f680f33) ok
 source "(%rdi)" (0x00000000) not located in a known VMA region (needed readable region)!
 destination "%rdi" ok
SegvReason: reading NULL VMA
Signal: 11
SourcePackage: extace
StacktraceTop:
 fftw_execute (p=0x0) at execute.c:24
 run_fft ()
 input_chewer ()
 draw ()
 ?? () from /usr/lib/libglib-2.0.so.0
Title: extace crashed with SIGSEGV in fftw_execute()
Uname: Linux 2.6.31-3-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

[Apport retracing service (apport)]

StacktraceTop:?? ()

[Vassily Gavrilyak (gavrilyak)]

From the stacktrace is clear that plan is NULL fftw_execute (p=0x0).
This happens because fftw_plan_r2r_1d doesn't work for some reason with new fftw version from karmic.
I have the same problem in my own application.
This bug should be assigned to libfft, not extace. The question remains whether it is libfft problem or ubuntu configuration problem.

[Dana Goyette (danagoyette)]

Judging based on the "I have the same problem in my own application" comment, I'm marking this as confirmed in libfftw.

[Paul (paulgfx)]

I did the debugging of extace and I found out the problem:
In main.c there is a line:
plan = fftw_plan_r2r_1d(nsamp, raw_fft_in,raw_fft_out, FFTW_R2HC, FFTW_FORWARD|FFTW_ESTIMATE);

You need to remove FFTW_FORWARD and the line becomes:

plan = fftw_plan_r2r_1d(nsamp, raw_fft_in,raw_fft_out, FFTW_R2HC, FFTW_ESTIMATE);

Now it works perfectly. It seems that fftw refuses to make a fft plan with FFTW_R2HC & FFTW_FORWARD (FFTW_R2HC already implies forward fft).
Paul

[Julian Taylor (jtaylor)]

this is an issue in the user code not fftw3. The transform sign must not be confused with flags.
so I'm closing this bug.