On Mon, Jun 27, 2011 at 4:43 PM, Josh Durgin <josh.durgin@xxxxxxxxxxxxx> wrote: > 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 > -- 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
