Ah, I use 64 bit system.

Argh. Forget the note about core dumps, I was changing this report too many times :[

I don't know why, but gdb displays frame #0 a bit different, when "bt" is run
for the first time. So, creating midi input gives the following:

#0 
LinuxSampler::SynchronizedConfig<std::vector<LinuxSampler::VirtualMidiDevice*,
std::allocator<LinuxSampler::VirtualMidiDevice*> > >::SwitchConfig
(this=0x631ab8) at
../../engines/../drivers/audio/../../common/SynchronizedConfig.h:146
146             atomic_thread_fence(memory_order_seq_cst);

and creating audio output causes something similar:

#0  LinuxSampler::SynchronizedConfig<bool>::SwitchConfig (this=0x61e108) at
SynchronizedConfig.h:146
146             atomic_thread_fence(memory_order_seq_cst);

Other lscp commands work fine (although I did not test them all...).
Let me know, if You need more info.

Thanks for the report. I committed a fix.

Hmmm...

I'm not sure whether it is related to this fix or to "fixed configure so it
detects x86_64", but now I can't even start linuxsampler, it crashes
immediately, backtrace looks as folows:

#4  <signal handler called>
 > > > >No locals.
#5  _Alloc_hider ()
    at
/usr/src/debug/gcc-4.3.2-20081105/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/basic_string.h:260
260             : _Alloc(__a), _M_p(__dat) { }
Current language:  auto; currently c++
No locals.
#6  basic_string (this=0x7698440, __s=<value optimized out>, __a=@0x7fff0769832f)
    at
/usr/src/debug/gcc-4.3.2-20081105/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/basic_string.tcc:221
221                                    __s + npos, __a), __a)
No locals.
#7  0x000000000075101a in Features::featuresAsString () at Features.cpp:69
69          String sFeatures = "none";
sFeatures = DWARF-2 expression error: DW_OP_reg operations must be used either
alone or in conjuction with DW_OP_piece.
#8  0x0000000000402f41 in main (argc=1, argv=0x7fff07698558) at linuxsampler.cpp:164
164             dmsg(1,("Detected features: %s\n",
Features::featuresAsString().c_str()));
sact = {__sigaction_handler = {sa_handler = 0x4034d0 <signal_handler(int)>,
sa_sigaction = 0x4034d0 <signal_handler(int)>}, sa_mask = {
    __val = {0 <repeats 16 times>}}, sa_flags = 0, sa_restorer = 0x4024a8
<_ZNSt8ios_base4InitD1Ev@plt>}

Forget it! Forget it!
It crashes only, when compiled with debug info, so this time it is rather
debugger bug.

I have the same issue with the latest cvs version - 2008-12-14, but only when
compiling with gcc version (Debian 4.3.2-1) 4.3.2

(gdb) --- Stacktrace
#0  0x00002ae3ce2cd5b5 in waitpid () from /lib/libpthread.so.0
#1  0x00002ae3cd693254 in DumpStack (format=<value optimized out>) at
stacktrace.c:446
#2  0x00002ae3cd6932f0 in StackTrace () at stacktrace.c:715
#3  0x000000000040375c in signal_handler (iSignal=11) at linuxsampler.cpp:270
#4  <signal handler called>
#5  0x00002ae3cdbbcee8 in std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::basic_string () from /usr/lib/libstdc++.so.6
#6  0x00002ae3cd692dca in Features::featuresAsString () at Features.cpp:69
#7  0x0000000000403171 in main (argc=1, argv=0x7fffdd78bc48) at linuxsampler.cpp:164
--- Symbols
#4  <signal handler called>
 > > > >No symbol table info available.
#5  0x00002ae3cdbbcee8 in std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::basic_string () from /usr/lib/libstdc++.so.6
No symbol table info available.
#6  0x00002ae3cd692dca in Features::featuresAsString () at Features.cpp:69
69          String sFeatures = "none";
sFeatures = {static npos = 18446744073709551615,
  _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> =
{<No data fields>}, <No data fields>},
    _M_p = 0xdd78bb30 <Address 0xdd78bb30 out of bounds>}}
#7  0x0000000000403171 in main (argc=1, argv=0x7fffdd78bc48) at linuxsampler.cpp:164
164             dmsg(1,("Detected features: %s\n",
Features::featuresAsString().c_str()));
sact = {__sigaction_handler = {sa_handler = 0x403700 <signal_handler(int)>,
sa_sigaction = 0x403700 <signal_handler(int)>}, sa_mask = {__val = {
      0 <repeats 16 times>}}, sa_flags = 0, sa_restorer = 0x4026e0
<_ZNSt8ios_base4InitD1Ev@plt>}
---

When recompiled it with gcc 4.2.4 (Debian 4.2.4-4) it's ok

Note that this bugzilla report is about two different bugs. The crash in
SynchronizedConfig was introduced 2008-11-02 and fixed 2008-11-30.

The other crash, in Features, is stranger and not solved. Grigor, are you also
running a 64-bit system?

The last crash IMO is caused rather by compiler (or debugger) bug. It hapens,
when Linuxsampler is compiled with options "-g -O2". It does NOT crash, when I
compile it with "-g0 -O2" or "-gcoff" (without optimizations), or "-mtune=core2
-g -O2".
And it is not "crash in Features", it happens in several different places.

So can this be considered to be a bug in GCC et. al. or a bug in LS?

Yes, my system is 64-bit.
I don't know whether it's a bug in GCC or LS, but in both cases I think we
should keep it open for now to lower the chances for duplicates of this bug :)

After getting a tip from marcusb at #linuxsampler, I committed a fix for the CPU
feature detection on x86_64. Grigor and arus, it would be great if you could
check if this bug is gone now.

(In reply to comment #12)
> After getting a tip from marcusb at #linuxsampler, I committed a fix for the CPU
> feature detection on x86_64. Grigor and arus, it would be great if you could
> check if this bug is gone now.

Looks like it's fixed now :)

Indeed, it seems to be fixed :)

Close this finally! ;)

marked as fixed :)