[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] Subversion checkins

From: Josh Green
Subject: Re: [fluid-dev] Subversion checkins
Date: Mon, 17 Sep 2007 10:23:46 -0700

Hello David,

On Mon, 2007-09-17 at 03:24 -0500, David Hilvert wrote:
> On Sun, 16 Sep 2007 18:02:34 -0700
> Josh Green <address@hidden> wrote:
> > I'm having trouble re-producing the QSynth crash problem (as mentioned
> > in a previous email to the list, forgot to CC you though).  
> I think I'm on the list.
> > I've tried with Jack and ALSA, QSynth 2.5, 2.6 and 3.1.  Also tried
> > FluidSynth with LADSPA and QSynth meters enabled.  
> Crashes seem to be produced frequently with the following configuration:
> Qsynth 2.5 or 3.1 with meters enabled
> ALSA audio driver
> synth.ladspa.active=no

Ok, so the synth.ladspa.active=no, but did you compile FluidSynth with
the --enable-ladspa option?

> > When the application crashes at line 1828 in fluid_synth.c (as your
> > backtrace indicates), please run the following 2 GDB commands (prints
> > the values of the i and di variables respectively):
> > 
> > p i
> > p di
> (gdb) p i
> $1 = 0
> (gdb) p di
> $2 = -1209854928

Well that di index variable is what is crashing it.  I wasn't expecting
that, since the code which assigns and updates di is really straight
forward, and I don't see how it could get the value shown there, unless
some other code is trampling over the dither_index field of the Synth
instance, which is likely what is happening.

> > Those are the only 2 variables that could cause a crash in the line of
> > code where it is occurring (provided the 'lin' buffer is valid for the
> > given 'len' samples).  Hopefully that gives some insight, although
> > looking over the code, I don't see how they could be out of range.  What
> > architecture are you running on? (is it 64 bit for example).  
> gdb qsynth

> The hardware supports 64-bit instructions, and is multi-core (Core 2 Duo).  
> The
> library and qsynth executable are 32-bit, according to the output of 'file':
> /usr/local/bin/qsynth: ELF 32-bit LSB executable, Intel 80386, version 1 
> (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), not 
> stripped
> /usr/local/lib/libfluidsynth.so.1.1.1: ELF 32-bit LSB shared object, Intel 
> 80386, version 1 (SYSV), not stripped

I wonder if your system being 64 bit capable is a determining factor for
this issue.  Perhaps make sure there are no other FluidSynth headers or
libraries installed elsewhere on your system, then re-build/install
FluidSynth.  Maybe at some point the code is treating those integers as
64 bit, and other code is treating it as 32 bit or something.

The next step would be to see what dither_index is being initialized to
at line 552 in fluid_synth.c and at what point it gets corrupted.  If
you're up for the task, here are some commands to run in gdb (after
starting up your gdb session with qsynth):

b main

b fluid_synth.c:555

p synth->dither_index
p sizeof (synth->dither_index)
b fluid_synth.c:1824
b fluid_synth.c:1846

p synth->dither_index
p di

p synth->dither_index
p di

Each set of commands (separated by a newline) can be copied and pasted
to the GDB shell (make sure the newline of the last command in the group
gets included, so that it acts as if the ENTER key was pressed).  If you
could send the resulting output, it might lead to some more insight as
to what is going on.

> > Are you certain that you are running with the latest FluidSynth?  Perhaps 
> > try
> > a fresh checkout if unsure.
> svn reports "At revision 117."

That is the latest, I was just thinking that perhaps there could be some
sort of build issue at work, if you updated from a previous version,
versus checking it out fresh.

Thanks for looking into this issue!  I have access to a core duo system,
which I'll give this a try on, to see if I can reproduce the problem.

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]