Sorry, master has a fix now for that also.
76efd9772c60b93bbf632e3ecc3b9117dc081427
-Sam
On Wed, Jul 18, 2012 at 8:29 AM, Jim Schutt <jaschut@xxxxxxxxxx> wrote:
> On 07/17/2012 06:03 PM, Samuel Just wrote:
>>
>> master should now have a fix for that, let me know how it goes. I opened
>> bug #2798 for this issue.
>>
>
> Hmmm, it seems handle_osd_ping() now runs into a case
> where for the first ping it gets, service.osdmap can be empty?
>
> 0> 2012-07-18 09:17:23.977497 7fffe6ec6700 -1 *** Caught signal
> (Segmentation fault) **
> in thread 7fffe6ec6700
>
> ceph version 0.48argonaut-419-g4e1d973
> (commit:4e1d973e466cd45138f004e84ab8631d9b2a60fa)
> 1: /usr/bin/ceph-osd() [0x723c39]
> 2: (()+0xf4a0) [0x7ffff76584a0]
> 3: (OSD::handle_osd_ping(MOSDPing*)+0x7d4) [0x5d7894]
> 4: (OSD::heartbeat_dispatch(Message*)+0x71) [0x5d8111]
> 5: (SimpleMessenger::DispatchQueue::entry()+0x583) [0x7d5103]
> 6: (SimpleMessenger::dispatch_entry()+0x15) [0x7d6485]
> 7: (SimpleMessenger::DispatchThread::entry()+0xd) [0x79523d]
> 8: (()+0x77f1) [0x7ffff76507f1]
> 9: (clone()+0x6d) [0x7ffff6aa1ccd]
>
> gdb has this to say:
>
> (gdb) bt
> #0 0x00007ffff765836b in raise (sig=11) at
> ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:42
> #1 0x0000000000724067 in reraise_fatal (signum=11) at
> global/signal_handler.cc:58
> #2 handle_fatal_signal (signum=11) at global/signal_handler.cc:104
> #3 <signal handler called>
> #4 get_epoch (this=0x15d0000, m=0x1587000) at ./osd/OSDMap.h:210
> #5 OSD::handle_osd_ping (this=0x15d0000, m=0x1587000) at osd/OSD.cc:1711
> #6 0x00000000005d8111 in OSD::heartbeat_dispatch (this=0x15d0000,
> m=0x1587000) at osd/OSD.cc:2769
> #7 0x00000000007d5103 in ms_deliver_dispatch (this=0x1472960) at
> msg/Messenger.h:504
> #8 SimpleMessenger::DispatchQueue::entry (this=0x1472960) at
> msg/SimpleMessenger.cc:367
> #9 0x00000000007d6485 in SimpleMessenger::dispatch_entry (this=0x1472880)
> at msg/SimpleMessenger.cc:384
> #10 0x000000000079523d in SimpleMessenger::DispatchThread::entry
> (this=<value optimized out>) at ./msg/SimpleMessenger.h:807
> #11 0x00007ffff76507f1 in start_thread (arg=0x7fffe6ec6700) at
> pthread_create.c:301
> #12 0x00007ffff6aa1ccd in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> (gdb) f 5
> #5 OSD::handle_osd_ping (this=0x15d0000, m=0x1587000) at osd/OSD.cc:1711
> 1711 m->stamp);
> (gdb) l
> 1706 }
> 1707 }
> 1708 Message *r = new MOSDPing(monc->get_fsid(),
> 1709 curmap->get_epoch(),
> 1710 MOSDPing::PING_REPLY,
> 1711 m->stamp);
>
> 1712 hbserver_messenger->send_message(r, m->get_connection());
> 1713
> 1714 if (curmap->is_up(from)) {
> 1715 note_peer_epoch(from, m->map_epoch);
> (gdb) p curmap
> $1 = std::tr1::shared_ptr (empty) 0x0
>
> -- Jim
>
>
>> Thanks for the info!
>> -Sam
>>
>> On Tue, Jul 17, 2012 at 2:54 PM, Jim Schutt<jaschut@xxxxxxxxxx> wrote:
>>>
>>> On 07/17/2012 03:44 PM, Samuel Just wrote:
>>>>
>>>>
>>>> Not quite. OSDService::get_osdmap() returns the most recently
>>>> published osdmap. Generally, OSD::osdmap is safe to use when you are
>>>> holding the osd lock. Otherwise, OSDService::get_osdmap() should be
>>>> used. There are a few other things that should be fixed surrounding
>>>> this issue as well, I'll put some time into it today. The map_lock
>>>> should probably be removed all together.
>>>
>>>
>>>
>>> Thanks for taking a look. Let me know when
>>> you get something, and I'll take it for a spin.
>>>
>>> Thanks -- Jim
>>>
>>>> -Sam
>>>
>>>
>>>
>>>
>>
>>
>
>
--
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
