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

Thu May 14 05:21:33 PDT 2009

Hello again!

Below the text of this email you find a debug output from gdb (with a
backtrace). Note (like I wrote in my last email) that I only see this
kind of difficulties when I include several user-defined classes in
the build. As soon as I try to declare objects of the classes
"poly_FIR_interp" or "poly_FIR_dec" in my code it causes programs that
are using my processing library to crash, when loading the library.
This shows that it is enough to try to construct objects of my user
defined classes (with empty default constructors) for the crash to
occur. I have never had any problems when I include only the
processing class in the build. The problems are therefore likely
connected to the dynamic link process (and my lack of knowledge of
it). I attach the source code (both as a zip-file and a gzip file).
Note that there is one sconstruct file for creating a standalone
program that tries out the processing (that I used for debugging) and
one that creates the plugin. The one used when packaged for this email
is the plugin creator.

Debug output:

(gdb) r bruce.mp3
Starting program: /home/mikael/clamprogs/tryoutDecIntdebug/MyProgram bruce.mp3
[Thread debugging using libthread_db enabled]
warning: Lowest section in /usr/lib/libicudata.so.38 is .hash at 000000d4
[New Thread 0xb5450920 (LWP 21446)]
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb5450920 (LWP 21446)]
0xb7fc8430 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fc8430 in __kernel_vsyscall ()
#1  0xb6c3a8a0 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb6c3c268 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb6e5f778 in __gnu_cxx::__verbose_terminate_handler ()
   from /usr/lib/libstdc++.so.6
#4  0xb6e5d655 in ?? () from /usr/lib/libstdc++.so.6
#5  0xb6e5d692 in std::terminate () from /usr/lib/libstdc++.so.6
#6  0xb6e5d6b5 in ?? () from /usr/lib/libstdc++.so.6
#7  0xb6e5cfe8 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.6
#8  0xb740787b in CLAM::Factory<CLAM::Processing>::CreateSafe ()
   from /usr/lib/libclam_core.so.13
#9  0xb7402f17 in CLAM::FlattenedNetwork::AddProcessing ()
   from /usr/lib/libclam_core.so.13
#10 0xb73ffa83 in CLAM::FlattenedNetwork::AddProcessing ()
   from /usr/lib/libclam_core.so.13
#11 0x0804ea8d in main (argc=Cannot access memory at address 0x53c6
) at main.cxx:17

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
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: decInt.zip
Type: application/zip
Size: 22592 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-users-clam-project.org/attachments/20090514/907f4fed/attachment-0003.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: decInt.tar.gz
Type: application/x-gzip
Size: 13972 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-users-clam-project.org/attachments/20090514/907f4fed/attachment-0003.bin>