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 -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
