qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Qemu + RBD = ceph::buffer::end_of_buffer


From: Josh Durgin
Subject: Re: [Qemu-devel] Qemu + RBD = ceph::buffer::end_of_buffer
Date: Fri, 06 May 2011 12:51:37 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Lanikai/3.1.9

CCing the ceph list.

On 05/06/2011 12:23 PM, Dyweni - Qemu-Devel wrote:
Hi List!

I upgraded Ceph to the latest development version
        Commit: 0edbc75a5fe8c3028faf85546f3264d28653ea3f
        Pulled from: git://ceph.newdream.net/ceph.git

I recompiled the latest GIT version of QEMU-KVM (with Josh Durgin's
patches) against the latest git version of Ceph.

However, this error is still occurring:

terminate called after throwing an instance of 'ceph::buffer::end_of_buffer'
   what():  buffer::end_of_buffer
Aborted (core dumped)



Here's another backtrace from GDB:

#0  0x00007f16ff829495 in raise (sig=<value optimized out>) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007f16ff82a81f in abort () at abort.c:92
#2  0x00007f16fed74a25 in __gnu_cxx::__verbose_terminate_handler () at
/usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/vterminate.cc:93
#3  0x00007f16fed71c64 in __cxxabiv1::__terminate (handler=0x7f16fed74817
<__gnu_cxx::__verbose_terminate_handler()>)
     at
/usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/eh_terminate.cc:38
#4  0x00007f16fed71c8c in std::terminate () at
/usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/eh_terminate.cc:48
#5  0x00007f16fed71ea4 in __cxxabiv1::__cxa_throw (obj=0x1346470,
tinfo=0x7f1701952ce0, dest=0x7f17017403d4
<ceph::buffer::end_of_buffer::~end_of_buffer()>)
     at
/usr/src/debug/sys-devel/gcc-4.4.5/gcc-4.4.5/libstdc++-v3/libsupc++/eh_throw.cc:83
#6  0x00007f1701740a7b in ceph::buffer::list::iterator::copy
(this=0x7f16fd8b1930, len=4, dest=0x7f16fd8b18dc "") at
include/buffer.h:379
#7  0x00007f1701743328 in decode_raw<__le32>  (address@hidden, p=...) at
include/encoding.h:35
#8  0x00007f170174198a in decode (address@hidden, p=...) at
include/encoding.h:80
#9  0x00007f1701741ade in decode (s=..., p=...) at include/encoding.h:189
#10 0x00007f17012e8369 in
librados::RadosClient::C_aio_sparse_read_Ack::finish (this=0x7f16f40d6200,
r=0) at librados.cc:463
#11 0x00007f170132bb5a in Objecter::handle_osd_op_reply (this=0x13423e0,
m=0x1346520) at osdc/Objecter.cc:794
#12 0x00007f17012d1444 in librados::RadosClient::_dispatch
(this=0x133f810, m=0x1346520) at librados.cc:751
#13 0x00007f17012d1244 in librados::RadosClient::ms_dispatch
(this=0x133f810, m=0x1346520) at librados.cc:717
#14 0x00007f170131b57b in Messenger::ms_deliver_dispatch (this=0x1341910,
m=0x1346520) at msg/Messenger.h:98
#15 0x00007f17013090d3 in SimpleMessenger::dispatch_entry (this=0x1341910)
at msg/SimpleMessenger.cc:352
#16 0x00007f17012e296e in SimpleMessenger::DispatchThread::entry
(this=0x1341da0) at msg/SimpleMessenger.h:533
#17 0x00007f170131a39b in Thread::_entry_func (arg=0x1341da0) at
common/Thread.h:41
#18 0x00007f1701f6dac4 in start_thread (arg=<value optimized out>) at
pthread_create.c:297
#19 0x00007f16ff8c838d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115

I haven't seen that error before, but it's probably a bug in the OSD where it doesn't set an error code. If you've still got the core file, could you go to frame 10 and send us the values of r, bl._len, and iter.off?

Thanks,
Josh



reply via email to

[Prev in Thread] Current Thread [Next in Thread]