Fwd: ceph

[Martin Wilderoth <martin.wilderoth@linserv.se>]

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