Re: [fluid-dev] Subversion checkins

[Josh Green]

Hello David,

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've tried
with Jack and ALSA, QSynth 2.5, 2.6 and 3.1.  Also tried FluidSynth with
LADSPA and QSynth meters enabled.  This isn't to say there isn't a
problem.  But if you could help me get some more info from gdb when the
crash happens, that could be very helpful.

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

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).  Are you
certain that you are running with the latest FluidSynth?  Perhaps try a
fresh checkout if unsure.

Best regards,
        Josh


On Fri, 2007-09-07 at 18:40 +0100, Rui Nuno Capela wrote:
> David Hilvert wrote:
> > On Wed, 5 Sep 2007 14:38:36 +0100 (WEST)
> > "Rui Nuno Capela" <address@hidden> wrote:
> > 
> >> two questions, no solution, but might help pointing out the offender:
> >>
> >> 1) is fluidsynth built for debug (-g)?
> > 
> > Building with -g gives the following slightly more detailed result:
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread -1318044784 (LWP 31842)]
> > 0xb7eb2f4b in fluid_synth_dither_s16 (synth=0x8174860, len=940, 
> > lin=0x89eec68, rin=0x89efb20, 
> >     lout=0x89f09d8, loff=0, lincr=2, rout=0x89f09d8, roff=1, rincr=2) at 
> > fluid_synth.c:1828
> > 1828        left_sample = roundi (lin[i] * 32766.0f + rand_table[0][di]);
> > (gdb) where
> > #0  0xb7eb2f4b in fluid_synth_dither_s16 (synth=0x8174860, len=940, 
> > lin=0x89eec68, rin=0x89efb20, 
> >     lout=0x89f09d8, loff=0, lincr=2, rout=0x89f09d8, roff=1, rincr=2) at 
> > fluid_synth.c:1828
> > #1  0xb7e90652 in fluid_alsa_audio_run_s16 (d=0x8111dc0) at fluid_alsa.c:558
> > #2  0xb7e6e2d3 in start_thread () from /lib/libpthread.so.0
> > #3  0xb73cf2fe in clone () from /lib/libc.so.6
> > 
> >> 2) are qsynth's output meters enabled?
> > 
> > The problem seems to be reproducible when output meters are enabled, and 
> > does
> > not seem to occur when the meters are disabled.
> 
> that's what my suspicion was.
> 
> qsynth is forking the audio path with new_fluid_audio_driver2() when the
> output meters are enabled.
> 
> maybe this route in fluidsynth is not very well optimized in regard to
> data alignment for instance or else something even worse and hideous...
> 
> on macosx it was known to crash almost exactly as this, isn't that so
> Ebrahim? but iirc latest reports say the situation seems to have been
> cleared ;)
> 
> until someone gives some respect to this seldom used fluidsynth code
> path, you better turn off those qsynth output meters, it's only
> eye-candy anyway :(
> 
> bye now