Hide Forgot
Created attachment 562180 [details] qpidd coredump Description of problem: Service qpidd fails to start because qpidd crashes. Version-Release number of selected component (if applicable): qpid-cpp-server-0.12-6.el6.x86_64 How reproducible: Always. Steps to Reproduce: 1. # /usr/sbin/qpidd --data-dir /var/lib/qpidd --daemon 2. 3. Actual results: $ /usr/sbin/qpidd --data-dir /var/lib/qpidd --daemon Segmentation fault (core dumped) Expected results: Not printed segmentation fault Additional info: $ strace /usr/sbin/qpidd --data-dir /var/lib/qpidd --daemon pipe([5, 6]) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f566ce82a70) = 8673 close(6) = 0 select(1024, [5], NULL, NULL, {600, 0}) = 1 (in [5], left {599, 985142}) read(5, "(\26", 2) = 2 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV (core dumped) +++ Segmentation fault (core dumped) $ pgrep qpidd 8673 $ ps o pid,ppid,comm p 8673 PID PPID COMMAND 8673 1 qpidd $ netstat -ln | grep 5672 tcp 0 0 0.0.0.0:5672 0.0.0.0:* LISTEN Therefore I believe that the parent process tries to read from unnamed pipe to unmapped memory and dies on SIGSEGV. But it's child (which is supposed to write to the pipe?) is still running (reparented to init process), waiting and blocking port 5672.
Created attachment 565981 [details] backtrace
Created attachment 565982 [details] threads
Our customer also faced same problem. But they have 2 system which following package installed. qpid-cpp-server-0.12-6.el6.x86_64 But when they tried start qpidd manually, System-A died on SIGSEGV, but System-B works fine. I asked the customer to send me sosreport, and I found some differences in each package list. System-A (died) has following packages nss-3.13.1-6.el6_2.x86_64 nss-sysinit-3.13.1-6.el6_2.x86_64 nss-tools-3.13.1-6.el6_2.x86_64 nss-util-3.13.1-3.el6_2.x86_64 System-B (works fine) > nss-3.12.10-17.el6_2.x86_64 > nss-sysinit-3.12.10-17.el6_2.x86_64 > nss-tools-3.12.10-17.el6_2.x86_64 > nss-util-3.12.10-2.el6.x86_64 It seems that this behaviour is depend on version of nss-* packages.
> It seems that this behaviour is depend on version of nss-* packages. Yes it is. A possible workaround that shall help is to _not_ using --daemon option on broker startup (i.e. not starting it via service / as a daemon).
I see, I'll suggest it for the customer, thanks.
*** This bug has been marked as a duplicate of bug 797426 ***
This segfault is due to the nss upgrade. Downgrading nss to nss-3.12.10-17 will work around this until a new nss is released, which should be shortly.