From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Wilderoth Subject: Fwd: ceph Date: Tue, 28 Jun 2011 21:14:50 +0200 (CEST) Message-ID: <683993917.17841.1309288490367.JavaMail.root@mail.linserv.se> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: Received: from 194-17-14-101.customer.telia.com ([194.17.14.101]:35030 "EHLO mail.linserv.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750852Ab1F1TXe (ORCPT ); Tue, 28 Jun 2011 15:23:34 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.linserv.se (Postfix) with ESMTP id 3FC9912002C for ; Tue, 28 Jun 2011 21:14:51 +0200 (CEST) Received: from mail.linserv.se ([127.0.0.1]) by localhost (mail.linserv.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lef9r7GOSE64 for ; Tue, 28 Jun 2011 21:14:50 +0200 (CEST) Received: from mail.linserv.se (mail.linserv.se [194.17.14.101]) by mail.linserv.se (Postfix) with ESMTP id 8982B120029 for ; Tue, 28 Jun 2011 21:14:50 +0200 (CEST) In-Reply-To: Sender: ceph-devel-owner@vger.kernel.org List-ID: To: ceph-devel v0.30 solved my problem :-) >> On 06/25/2011 08:05 PM, Martin Wilderoth wrote: >>> >>> This is the backtrace of the dump: >>> >>> Core was generated by `ceph -w'. >>> Program terminated with signal 11, Segmentation fault. >>> #0 0x0000000000467f6f in ceph_tool_data::ceph_tool_data() () >>> (gdb) bt >>> #0 0x0000000000467f6f in ceph_tool_data::ceph_tool_data() () >>> #1 0x000000000044c31c in ?? () >>> #2 0x000000000052bbad in __libc_csu_init () >>> #3 0x00007fac02f49e40 in __libc_start_main () >>> from /lib/x86_64-linux-gnu/libc.so.6 >>> #4 0x000000000044d2e1 in _start () >>> >>> /regards Martin >> >> This is one of the globals that was removed recently in master (which will >> be in 0.31 or 0.32). One of the problems with them was that the order of >> initialization is undefined, which may be the reason for this crash. Someone >> reported that being a problem when compiling ceph with gcc 4.6. >> >> I'd suggest compiling with gcc 4.4, or using the master branch. >> >> Josh >I did some testing of my own and it looks like in the stable branch, >it decides to initialize g_ceph_context really early, which is good, >but then decides to put off initializing g_conf until much, much >later. Unfortunately, init_priority cannot be applied to references, >which g_conf is in the stable branch. Also, references can't be >reseated after they're initialized, so nobody else can initialize >g_conf except itself. >So in conclusion, it would be pretty difficult to fix in the stable >branch. I think maybe the best thing to do is to move to master, where >this is all fixed, if it pops up for you. >As Sam commented, we have eliminated all non-trivial global >constructors for exactly these reasons. >sincerely, >Colin