Hi Brad, On Wed, Apr 27, 2016 at 11:40:40PM -0400, Brad Hubbard wrote: [...] > > 000000000030a810 <_Z13pidfile_writePK11md_config_t@@Base>: > > ... > > 30b09d: e8 0e 40 e4 ff callq 14f0b0 <backtrace@plt> > > 30b0a2: 4c 89 ef mov %r13,%rdi > > ------- > > ... > > > > So either we tripped backtrace() code from pidfile_write() _or_ we can't > > trust the stack. From the log snippet, it looks that we're far past the point > > at which we would write a pidfile to disk (ie. at process start during > > global_init()). > > Rather, we're actually handling a request and outputting some bit of debug > > message > > via MSDOp::print() and beyond... > > It would help to know what binary this is and what OS. > > We know the offset into the function is 0x30b0a2 but we don't know which > function yet AFAICT. Karol, how did you arrive at pidfile_write? Purely from > the offset? I'm not sure that would be reliable... Correct, from the offset. Let me clarify, I don't think pidfile_write() is the function in which we segfaulted :) Hence my suspicion of a blown stack. I don't know the specifics behind the backtrace call used to generate this stack... so maybe this is a naive question... but why do you think the offset is unreliable? Perhaps I'm not reading this trace correctly? > > This is a segfault so the address of the frame where we crashed should be the > exact instruction where we crashed. I don't believe a mov from one register to > another that does not involve a dereference ((%r13) as opposed to %r13) can > cause a segfault so I don't think we are on the right instruction but then, as > you say, the stack may be corrupt. Agreed... a mov between registers wouldn't cause a segfault. -- Regards, Karol
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
