From: Willem Jan Withagen <wjw@digiware.nl>
To: Sage Weil <sage@newdream.net>
Cc: Ceph Development <ceph-devel@vger.kernel.org>
Subject: Re: Compiling for FreeBSD, trouble in buffer.c
Date: Thu, 10 Dec 2015 16:03:21 +0100 [thread overview]
Message-ID: <56699439.3090006@digiware.nl> (raw)
In-Reply-To: <alpine.DEB.2.00.1511300518210.19170@cobra.newdream.net>
I have a failure in:
./unittest_erasure_code_shec_arguments
All tests befor this PASS. (other than rbd which is disabled to
the time being)
Which I traceback to code in ErasureCodeShec.cc
Line 218:
unsigned blocksize = (*chunks.begin()).second.length();
After a few iterations I get a "negative" blocksize, which causes
allocations further on to really thrash the system out of swap.
At first I expected it could be due to a Clang typecasting problem.
But after more debugging I found the following in
buffer.h
unsigned length() const {
#if 0
// DEBUG: verify _len
unsigned len = 0;
for (std::list<ptr>::const_iterator it = _buffers.begin();
it != _buffers.end();
it++) {
len += (*it).length();
}
assert(len == _len);
#endif
return _len;
}
Which suggests that debugging was needed at this point earlier in life.
If I enable this debug block, I do get the assert affected.
Now the next question is why? Given the debug snippet it needed
analyzing before.
And the derived question then is:
What is the easiest path to find out what is actually wrong here.
All suggestions welcome.
--WjW
next prev parent reply other threads:[~2015-12-10 15:04 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-29 17:44 Compiling for FreeBSD Willem Jan Withagen
2015-11-29 18:08 ` Haomai Wang
2015-11-29 18:57 ` Willem Jan Withagen
2015-11-30 3:46 ` Yan, Zheng
2015-11-30 6:58 ` Mykola Golub
2015-11-30 11:53 ` Willem Jan Withagen
2015-11-30 14:13 ` Mykola Golub
2015-11-30 14:40 ` Willem Jan Withagen
2015-11-30 16:04 ` Willem Jan Withagen
2015-11-30 16:20 ` Gregory Farnum
2015-12-01 9:42 ` Willem Jan Withagen
2015-12-01 12:22 ` Mykola Golub
2015-12-01 12:44 ` Willem Jan Withagen
2015-11-30 14:56 ` Willem Jan Withagen
2015-11-30 13:21 ` Sage Weil
2015-11-30 13:54 ` Willem Jan Withagen
2015-12-01 11:08 ` Willem Jan Withagen
2015-12-01 13:30 ` Sage Weil
2015-12-01 13:42 ` Willem Jan Withagen
2015-12-01 14:35 ` Sage Weil
2015-12-01 16:24 ` Willem Jan Withagen
2015-12-01 17:22 ` Alan Somers
2015-12-01 18:08 ` Willem Jan Withagen
2015-12-01 18:21 ` Alan Somers
2015-12-01 18:31 ` Willem Jan Withagen
2015-12-01 18:36 ` Sage Weil
2015-12-01 18:43 ` Willem Jan Withagen
2015-12-02 14:13 ` Yan, Zheng
2015-12-02 20:52 ` Willem Jan Withagen
2015-12-03 0:27 ` Yan, Zheng
2015-12-04 18:30 ` Willem Jan Withagen
2015-12-04 18:44 ` Gregory Farnum
2015-12-04 20:11 ` Willem Jan Withagen
2015-12-08 9:59 ` Willem Jan Withagen
2015-12-08 10:04 ` Willem Jan Withagen
2015-12-08 12:36 ` Mykola Golub
2015-12-08 15:59 ` Willem Jan Withagen
2015-12-01 18:51 ` Willem Jan Withagen
2015-12-02 21:10 ` Willem Jan Withagen
2015-12-02 22:47 ` Compiling for FreeBSD, missing rbd Willem Jan Withagen
2015-12-03 12:34 ` Mykola Golub
2015-12-03 13:27 ` Willem Jan Withagen
2015-12-03 9:50 ` Compiling for FreeBSD, runtimes for seperate tests Willem Jan Withagen
2015-12-03 14:12 ` Willem Jan Withagen
2015-12-03 21:06 ` Gregory Farnum
2015-12-05 12:56 ` Compiling for FreeBSD, Clang refuses to compile a test Willem Jan Withagen
2015-12-05 13:02 ` Xinze Chi (信泽)
2015-12-07 21:44 ` Willem Jan Withagen
2015-12-07 22:19 ` Michal Jarzabek
2015-12-08 0:29 ` Willem Jan Withagen
2015-12-08 8:48 ` Willem Jan Withagen
2016-01-16 12:56 ` Compiling for FreeBSD Willem Jan Withagen
2015-12-10 15:03 ` Willem Jan Withagen [this message]
2015-12-11 9:56 ` Compiling for FreeBSD, trouble in buffer.c Willem Jan Withagen
2016-01-15 10:52 ` Compiling for FreeBSD, Bluestore requires AIO Willem Jan Withagen
2016-01-15 11:21 ` Willem Jan Withagen
2016-01-15 17:30 ` Sage Weil
2016-01-15 18:34 ` Willem Jan Withagen
2016-01-18 9:54 ` Mykola Golub
2016-01-18 10:05 ` Willem Jan Withagen
2016-05-28 0:15 ` Compiling for FreeBSD Willem Jan Withagen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56699439.3090006@digiware.nl \
--to=wjw@digiware.nl \
--cc=ceph-devel@vger.kernel.org \
--cc=sage@newdream.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.