Re: ceph

Re: ceph

[Martin Wilderoth]

----- Ursprungligt meddelande ----- 
Från: "Yehuda Sadeh Weinraub" <yehudasa@gmail.com> 
Till: "Martin Wilderoth" <martin.wilderoth@linserv.se> 
Kopia: "ceph-devel" <ceph-devel@vger.kernel.org> 
Skickat: fredag, 24 jun 2011 20:39:30 
Ämne: Re: ceph 
Hello 

I have just installed all the system with the latest debian testing
and then installed ceph. The ceph-client-tools are reported
to be on latest version with apt-get install.

I just get Segmentation fault on the command line not sure how to backtrace.

I have managed to get a core dump not sure how to read that.

in the logfile I get the following messages

Jun 25 06:46:20 ceph1 kernel: [86215.823759] ceph[9395]: segfault at 328 ip 0000000000467f6f sp 00007fffa47e7580 error 4 in ceph[400000+169000]
Jun 25 06:48:25 ceph1 kernel: [86341.263661] ceph[9409]: segfault at 328 ip 0000000000467f6f sp 00007fff0b11a3a0 error 4 in ceph[400000+169000]


On Fri, Jun 24, 2011 at 12:41 AM, Martin Wilderoth 
<martin.wilderoth@linserv.se> wrote: 
> Hello, 
> 
> I get Segmentation fault when running the command ceph to check the status. I'm uning the deb packages deb http://ceph.newdream.net/debian/ sid main 
> 
> I have installed the testing distribution of Debian. 
> The other parts seems fine. The version of ceph is 0.29.1-1 
> 
Do you have a backtrace for that segfault? Did you update all the 
packages (including ceph-client-tools)? 

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

Fwd: ceph

[Martin Wilderoth]

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

>I have just installed all the system with the latest debian testing 
>and then installed ceph. The ceph-client-tools are reported 
>to be on latest version with apt-get install. 
>
>I just get Segmentation fault on the command line not sure how to backtrace. 
>
>I have managed to get a core dump not sure how to read that. 

>in the logfile I get the following messages 

>Jun 25 06:46:20 ceph1 kernel: [86215.823759] ceph[9395]: segfault at 328 ip >0000000000467f6f sp 00007fffa47e7580 error 4 in ceph[400000+169000] 
>Jun 25 06:48:25 ceph1 kernel: [86341.263661] ceph[9409]: segfault at 328 ip >0000000000467f6f sp 00007fff0b11a3a0 error 4 in ceph[400000+169000] 


>> Hello, 
>> 
>> I get Segmentation fault when running the command ceph to check the status. I'm uning the deb packages deb http://ceph.newdream.net/debian/ sid main 
>> 
>> I have installed the testing distribution of Debian. 
>> The other parts seems fine. The version of ceph is 0.29.1-1 
>> 
>Do you have a backtrace for that segfault? Did you update all the 
>packages (including ceph-client-tools)? 

>Yehuda 

Re: Fwd: ceph

[Josh Durgin]

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

Re: Fwd: ceph

[Colin McCabe]

On Mon, Jun 27, 2011 at 4:43 PM, Josh Durgin <josh.durgin@dreamhost.com> 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@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Fwd: ceph

[Martin Wilderoth]

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