Created attachment 68823 [details]
Small song which triggeres crasher

(In reply to comment #0)
> I've found a reproducable crash which crashes with both, gslice enabled and
> G_SLICE=always-malloc.
> 
> The method to reproduce the crash is:
> 
> 1. start beast -:L a2.bse
> 2. goto the BQS Queek Synth
> 3. open an FFT scope view for the biquad filter output
> 4. play the song

thanks, is reproducable here, on x86 with gtk+-2.6.4 (no gslice).

> #0  0x00002b21935cade0 in raise () from /lib/libc.so.6
> #1  0x00002b21935cc290 in abort () from /lib/libc.so.6
> #2  0x00002b219360101e in __fsetlocking () from /lib/libc.so.6
> #3  0x00002b2193606d7b in malloc_usable_size () from /lib/libc.so.6
> #4  0x00002b219360705e in free () from /lib/libc.so.6
> #5  0x00002b2191fd1eb1 in (anonymous namespace)::SourceProbes::handle_probe
> (this=0xe1b1e0, pdata=@0xe1ce90,
>     n_values=<value optimized out>, tick_stamp=48769, n_ostreams=1,
> ostreams_p=<value optimized out>) at bseprobe.cc:475

at this point,
475:        bse_engine_free_ostreams (n_ostreams, pdata.ostreams);
is called which is just a wrapper around g_free(pdata.ostreams);
verifying the passing of the ostreams pointer involved and finally
commenting out line 475 shows that it's not the culprit.

memory corruption has occoured before the ostreams in line 475 are freed.

> As you see, the stacktraces are not very different, and the same functions
> seem to be involved.

still, the corruption occoured before these functions are called.

Created attachment 68891 [details]
compressed valgrind log

this attached valgrind log shows the crash while running under valgrind 2.4.0.
the priority fo the scope handling code had to be slightly altered to get active
scopes under valgrind. for reproduction, just exchange line 341 of bstsnifferscope.c:
 g_idle_add_full (G_PRIORITY_LOW + 5, source_probe_idle_request, ...);
for:
 g_idle_add_full (0, source_probe_idle_request, ...);
that way, scopes updates run at the same prio as redraws and aren't supressed by an otherwise busy program.

Created attachment 68892 [details]
compressed valgrind log

second valgrind log, this time the offending line 475 in bseprobe.cc:
  // bse_engine_free_ostreams (n_ostreams, pdata.ostreams);
was commented out.
the program still crashes after a while. unfortunately both valgrind logs show assertions triggered in valgrind, so valgrinding the sessions with a newer version than 2.4.0 is probably a good idea.

due to massive amounts of underruns, the logs are best piped through:
  egrep -v "OSS: underrun detected|: no voice available for note-"
before being read.

nevertheless, both logs show suspicious invalid reads/accesses when converting a probe record and when using wmemcpy() or other bseblockutils functions.
running beast with --version in the same valgrind environment gives:
  CPU Float SIMD:   SSE SSE2 SSESYS
so apparently the SSE optimized versions got used when bseblockutils functions where called.

(In reply to comment #4)
> nevertheless, both logs show suspicious invalid reads/accesses when converting
> a probe record and when using wmemcpy() or other bseblockutils functions.
> running beast with --version in the same valgrind environment gives:
>   CPU Float SIMD:   SSE SSE2 SSESYS
> so apparently the SSE optimized versions got used when bseblockutils functions
> where called.

Although the valgrind log shows problems in the SSE optimized code, that doesn't seem to be the cause of the problem, as applying the following patch:

Index: birnetcpu.c
===================================================================
RCS file: /cvs/gnome/beast/birnet/birnetcpu.c,v
retrieving revision 1.2
diff -u -p -u -r1.2 birnetcpu.c
--- birnetcpu.c 15 Apr 2006 01:36:42 -0000      1.2
+++ birnetcpu.c 14 Jul 2006 12:27:40 -0000
@@ -20,6 +20,7 @@
 #include <setjmp.h>
 #include <signal.h>
 #include <string.h>
+#include <stdlib.h>

 /* figure architecture name from compiler */
 static const char*
@@ -213,6 +214,12 @@ get_x86_cpu_features (BirnetCPUInfo *ci,
       sigaction (SIGILL, &old_action, NULL);
     }

+  if (getenv ("BIRNET_DISABLE_SSE"))
+    {
+      g_printerr ("sse extensions disabled\n");
+      ci->x86_sse = ci->x86_sse2 = ci->x86_sse3 = ci->x86_ssesys = false;
+    }
+
   return true;
 }

and running beast with BIRNET_DISABLE_SSE=1 still crashes. I'll attach a valgrind log.

Created attachment 68958 [details]
compressed valgrind log (no SSE)

Valgrind log for crash without SSE instructions enabled (see comment #5), on AMD64.

(In reply to comment #5)
> (In reply to comment #4)
> > nevertheless, both logs show suspicious invalid reads/accesses when
> > converting

> Although the valgrind log shows problems in the SSE optimized code, that
> doesn't seem to be the cause of the problem, as applying the following patch:

i didn't claim it was the cause. the warnings should still be investigated though.

> +  if (getenv ("BIRNET_DISABLE_SSE"))
> +    {
> +      g_printerr ("sse extensions disabled\n");
> +      ci->x86_sse = ci->x86_sse2 = ci->x86_sse3 = ci->x86_ssesys = false;
> +    }

you do know of the output of beast --help? which gives you:
  --bse-force-fpu Disable loading of SSE or similarly optimized plugins

(In reply to comment #0)
> I've found a reproducable crash which crashes with both, gslice enabled and
> G_SLICE=always-malloc.
> 
> The method to reproduce the crash is:
> 
> 1. start beast -:L a2.bse
> 2. goto the BQS Queek Synth
> 3. open an FFT scope view for the biquad filter output
> 4. play the song

thanks for the report, fixed in 0.7.1:

Wed Dec 13 21:30:39 2006  Tim Janik  <timj@gtk.org>

        * bseenginemaster.c (master_take_probes): fixup ostreams[].value 
        pointers before returning a probe, since those may have been altered
        by process() routines.