[CLAM] Building and installing a processing object with Sconstruct and several shared objects

Mikael Andreen mikael at leiflandia.se
Mon May 18 03:55:13 PDT 2009


Hello,

I tracked down the problem. I am using the boost circular_buffer class
and it somehow makes my processing library crash when loaded.

The crash only occurs when the circular_buffer is used as a member
object of a class. Not when an object of circular_buffer is declared
locally within a function for example. The class
circular_buffer_space_optimized (an adaptor of the circular_buffer
with a different allocation strategy) doesn't cause the crash. "The
functionality of the circular_buffer_space_optimized is similar to the
base circular_buffer except it does not allocate memory at once when
created rather it allocates memory as needed". Maybe this difference
is what prevents the crash from happening. But I seen no reason why
the base one shouldn't work.

I prefer to use STL-compliant containers but now I'll probably switch
to the circular buffer class within CLAM to be sure things work as
supposed. Comments?

Best Regards, Mikael

On Wed, May 13, 2009 at 2:55 AM, David García Garzón
<dgarcia at iua.upf.edu> wrote:
> I would like to help you but I think we need more information. When a program
> crashes one can get a backtrace with gdb that will help to know where it is
> crashing. Often the crash is caused by a failed assertion and you will get the
> backtrace in the console without using gdb. Sometimes weird memory access can
> make later code to crash, in those situations valgrind is of great help. Of
> course, having the code would also help us to spot typical caveats with clam
> and c++. If it crashes on plugin loading you should review the registrator
> (cxx) and other global/static initialization you could have in your classes.
> Assure that you changed all the names when copying the example. If it crashes
> when creating a processing, (plugin loading and processing creation are
> different events) then you should check construction and configuration. A
> typical error is not being aware that Configure is called more than once.
> Symbol collision could be a problem but grep tells me we didn't defined
> poly_FIR_interp. If still in doubt, namespaces can help you.
>
> When linking a shared library, missing symbols are not reported. A trick to
> get the report is trying to build a program by linking the library as the only
> source.
> g++ libintDec.so  -o deleteme
> Still, if you get missing symbols and adding them solves the problem, then we
> have a bug in clam. The library should not load but it should not cause a
> crash.
>
> David.
>
> A Dimarts 12 Maig 2009 22:21:42, Mikael Andreen va escriure:
>> Hello!
>>
>> I found it easy to get started with CLAM using the examples on the
>> web. I have used the following Sconstruct file to build and install my
>> processings for use with the Network Editor:
>> http://clam-project.org/wiki/Building_a_processing_library. I however
>> have a problem when I construct more complex signal processing
>> programs. The problems occur when my processing class has members of
>> classes that I have written myself. When I use the Sconstruct file in
>> the link above to build my library, the Network editor crashes as soon
>> as I try to load my plugin (although my classes stand alone are
>> debugged and working) . I know very little about dynamic linking and
>> SConstruct so I would be glad if someone helped me out on how to write
>> a Sconstruct file that makes the linking right (if the SCons file is
>> the problem). I have three different classes: a class called intDec is
>> the processing object, poly_FIR_dec is a class used by the processing
>> object and likewise the class poly_FIR_interp. What happens when these
>> objects are shared? Can it be name-conflicts that make the processing
>> crash? Some features are similiar and named the same in poly_FIR_dec
>> and poly_FIR_interp for instance, is this a problem when the objects
>> are shared? Any thoughts on how to solve this problem and the correct
>> c++ programming practises surrounding it are welcome This is the
>> output from my compile process:
>>
>> scons: Reading SConscript files ...
>> scons: done reading SConscript files.
>> scons: Building targets ...
>> g++ -o poly_FIR_interp.os -c -g -O3 -Wall -fPIC -DCLAM_FLOAT
>> -DUSE_PTHREADS=1 -DUSE_XERCES=1 -DCLAM_USE_XML -DUSE_LADSPA=1
>> -DUSE_SNDFILE=1 -DUSE_OGGVORBIS=1 -DWITH_VORBIS=1 -DUSE_MAD=1
>> -DWITH_MAD=1 -DUSE_ID3=1 -DUSE_ALSA=1 -DUSE_JACK=1 -DUSE_PORTAUDIO=1
>> -DUSE_FFTW3=1 -I/usr/local/include -I/usr/include/alsa
>> poly_FIR_interp.cxx
>> g++ -o intDec.os -c -g -O3 -Wall -fPIC -DCLAM_FLOAT -DUSE_PTHREADS=1
>> -DUSE_XERCES=1 -DCLAM_USE_XML -DUSE_LADSPA=1 -DUSE_SNDFILE=1
>> -DUSE_OGGVORBIS=1 -DWITH_VORBIS=1 -DUSE_MAD=1 -DWITH_MAD=1 -
> DUSE_ID3=1
>> -DUSE_ALSA=1 -DUSE_JACK=1 -DUSE_PORTAUDIO=1 -DUSE_FFTW3=1
>> -I/usr/local/include -I/usr/include/alsa intDec.cxx
>> g++ -o poly_FIR_dec.os -c -g -O3 -Wall -fPIC -DCLAM_FLOAT
>> -DUSE_PTHREADS=1 -DUSE_XERCES=1 -DCLAM_USE_XML -DUSE_LADSPA=1
>> -DUSE_SNDFILE=1 -DUSE_OGGVORBIS=1 -DWITH_VORBIS=1 -DUSE_MAD=1
>> -DWITH_MAD=1 -DUSE_ID3=1 -DUSE_ALSA=1 -DUSE_JACK=1 -DUSE_PORTAUDIO=1
>> -DUSE_FFTW3=1 -I/usr/local/include -I/usr/include/alsa
>> poly_FIR_dec.cxx
>> g++ -o libintDec.so -shared poly_FIR_interp.os intDec.os
>> poly_FIR_dec.os -lclam_core -lclam_audioio -lclam_processing
>> scons: `install' is up to date.
>> scons: done building targets.
>>
>>
>> Best Regards, Mikael
>>
>> _______________________________________________
>> CLAM mailing list
>> CLAM at iua.upf.es
>> http://clam.iua.upf.edu
>
> --
> David García Garzón
> (Work) dgarcia at iua dot upf anotherdot es
> http://www.iua.upf.edu/~dgarcia
>
>




More information about the clam-users mailing list