Bug 108

Summary: Crash after commit made on 2008-11-02...
Product: LinuxSampler Reporter: arus
Component: otherAssignee: Andreas Persson <andreas56>
Status: CLOSED FIXED    
Severity: normal    
Priority: P2    
Version: SVN Trunk   
Hardware: PC   
OS: Linux   

Description arus 2008-11-29 11:56:43 CET
...entitled "added memory ordering constraints to improve stability on
multi-core and multi-cpu systems"

I work on multi-core system (OS: Fedora 10).

After that commit linuxsampler crashes every time when I try to create audio or
midi device using lscp commands (like "CREATE MIDI_INPUT_DEVICE ALSA").
The top lines of stack trace are included below (for some reason linuxsampler
does not produce core dumps after crash, so I can't send more detailed one)
LSCPServer: Client connection established on socket:5.

The backtrace (after CREATE MIDI_INPUT_DEVICE ALSA):

Program received signal SIGSEGV, Segmentation fault.
#0  0x00007ffff7d8f1fe in
LinuxSampler::SynchronizedConfig<std::vector<LinuxSampler::VirtualMidiDevice*,
std::allocator<LinuxSampler::VirtualMidiDevice*> > >::SwitchConfig
(this=0x631ab8) from /usr/local/lib64/linuxsampler/liblinuxsampler.so.1
#1  0x00007ffff7d8cbae in LinuxSampler::MidiInputPort::Connect (this=0x631370,
pDevice=0x626890) at MidiInputPort.cpp:517
#2  0x00007ffff7cf4420 in LinuxSampler::LSCPServer::EventHandler::MidiPortAdded
(this=0x61d548, pPort=0x631370) at lscpserver.cpp:253
#3  0x00007ffff7cf1dbd in
LinuxSampler::LSCPServer::EventHandler::MidiDeviceCreated (this=0x61d548,
pDevice=0x607d00) at lscpserver.cpp:224
#4  0x00007ffff7cbfc34 in LinuxSampler::Sampler::fireMidiDeviceCreated
(this=0x6070b0, pDevice=0x607d00) at Sampler.cpp:335
#5  0x00007ffff7cc0a0a in LinuxSampler::Sampler::CreateMidiInputDevice
(this=0x6070b0, MidiDriver=<value optimized out>,
    Parameters=<value optimized out>) at Sampler.cpp:635
#6  0x00007ffff7d0b7bf in LinuxSampler::LSCPServer::CreateMidiInputDevice
(this=0x61d390, Driver=DWARF-2 expression error: DW_OP_reg operations must be
used either alone or in conjuction with DW_OP_piece.
) at lscpserver.cpp:834
#7  0x00007ffff7cea246 in yyparse (yyparse_param=0x607a20) at lscp.y:342
#8  0x00007ffff7cf98e5 in LinuxSampler::LSCPServer::Main (this=0x61d390) at
lscpserver.cpp:570
#9  0x00007ffff7da1664 in __pthread_launcher (thread=0x61d390) at Thread.cpp:388
#10 0x0000003fbe2073da in start_thread () from /lib64/libpthread.so.0
#11 0x0000003fbd6e627d in clone () from /lib64/libc.so.6
Comment 1 arus 2008-11-29 11:58:51 CET
Ah, I use 64 bit system.
Comment 2 arus 2008-11-29 12:02:33 CET
Argh. Forget the note about core dumps, I was changing this report too many times :[
Comment 3 arus 2008-11-29 17:15:28 CET
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.
Comment 4 Andreas Persson 2008-11-30 10:13:22 CET
Thanks for the report. I committed a fix.
Comment 5 arus 2008-11-30 11:18:04 CET
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>}
Comment 6 arus 2008-11-30 11:38:35 CET
Forget it! Forget it!
It crashes only, when compiled with debug info, so this time it is rather
debugger bug.
Comment 7 Grigor Iliev 2008-12-14 22:41:46 CET
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
Comment 8 Andreas Persson 2008-12-15 19:29:43 CET
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?
Comment 9 arus 2008-12-16 08:17:19 CET
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.
Comment 10 Christian Schoenebeck 2008-12-16 13:25:11 CET
So can this be considered to be a bug in GCC et. al. or a bug in LS?
Comment 11 Grigor Iliev 2008-12-18 17:48:08 CET
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 :)
Comment 12 Andreas Persson 2009-01-16 20:13:15 CET
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.
Comment 13 Grigor Iliev 2009-01-17 18:39:30 CET
(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 :)
Comment 14 arus 2009-01-19 20:04:30 CET
Indeed, it seems to be fixed :)

Close this finally! ;)
Comment 15 Grigor Iliev 2009-01-24 15:38:24 CET
marked as fixed :)