From: Willem Jan Withagen <wjw@digiware.nl>
To: Gregory Farnum <gfarnum@redhat.com>
Cc: "Xinze Chi (信泽)" <xmdxcxz@gmail.com>,
"Ceph Development" <ceph-devel@vger.kernel.org>
Subject: Re: FreeBSD Building and Testing
Date: Wed, 6 Jan 2016 11:21:30 +0100 [thread overview]
Message-ID: <568CEAAA.9080602@digiware.nl> (raw)
In-Reply-To: <CAJ4mKGYgFw1Xx4SFbSpg0EYU-Suk8PG2exkVRDtDZ8fzjU1H9w@mail.gmail.com>
On 5-1-2016 19:23, Gregory Farnum wrote:
> On Mon, Dec 28, 2015 at 8:53 AM, Willem Jan Withagen <wjw@digiware.nl> wrote:
>> Hi,
>>
>> Can somebody try to help me and explain why
>>
>> in test: Func: test/mon/osd-crash
>> Func: TEST_crush_reject_empty started
>>
>> Fails with a python error which sort of startles me:
>> test/mon/osd-crush.sh:227: TEST_crush_reject_empty: local
>> empty_map=testdir/osd-crush/empty_map
>> test/mon/osd-crush.sh:228: TEST_crush_reject_empty: :
>> test/mon/osd-crush.sh:229: TEST_crush_reject_empty: ./crushtool -c
>> testdir/osd-crush/empty_map.txt -o testdir/osd-crush/empty_map.m
>> ap
>> test/mon/osd-crush.sh:230: TEST_crush_reject_empty: expect_failure
>> testdir/osd-crush 'Error EINVAL' ./ceph osd setcrushmap -i testd
>> ir/osd-crush/empty_map.map
>> ../qa/workunits/ceph-helpers.sh:1171: expect_failure: local
>> dir=testdir/osd-crush
>> ../qa/workunits/ceph-helpers.sh:1172: expect_failure: shift
>> ../qa/workunits/ceph-helpers.sh:1173: expect_failure: local 'expected=Error
>> EINVAL'
>> ../qa/workunits/ceph-helpers.sh:1174: expect_failure: shift
>> ../qa/workunits/ceph-helpers.sh:1175: expect_failure: local success
>> ../qa/workunits/ceph-helpers.sh:1176: expect_failure: pwd
>> ../qa/workunits/ceph-helpers.sh:1177: expect_failure: printenv
>> ../qa/workunits/ceph-helpers.sh:1178: expect_failure: echo ./ceph osd
>> setcrushmap -i testdir/osd-crush/empty_map.map
>> ../qa/workunits/ceph-helpers.sh:1180: expect_failure: ./ceph osd
>> setcrushmap -i testdir/osd-crush/empty_map.map
>> *** DEVELOPER MODE: setting PATH, PYTHONPATH and LD_LIBRARY_PATH ***
>> Traceback (most recent call last):
>> File "./ceph", line 936, in <module>
>> retval = main()
>> File "./ceph", line 874, in main
>> sigdict, inbuf, verbose)
>> File "./ceph", line 457, in new_style_command
>> inbuf=inbuf)
>> File "/usr/srcs/Ceph/wip-freebsd-wjw/ceph/src/pybind/ceph_argparse.py",
>> line 1208, in json_command
>> raise RuntimeError('"{0}": exception {1}'.format(argdict, e))
>> RuntimeError: "{'prefix': u'osd setcrushmap'}": exception "['{"prefix": "osd
>> setcrushmap"}']": exception 'utf8' codec can't decode b
>> yte 0x86 in position 56: invalid start byte
>>
>> Which is certainly not the type of error expected.
>> But it is hard to detect any 0x86 in the arguments.
>>
>> And yes python is right, there are no UTF8 sequences that start with 0x86.
>> Question is:
>> Why does it want to parse with UTF8?
>> And how do I switch it off?
>> Or how to I fix this error?
>
> I've not handled this myself but we've seen this a few times. The
> latest example in a quick email search was
> http://tracker.ceph.com/issues/9405, and it was apparently having a
> string which wasn't null-terminated.
Looks like in my case it was due to too large a mess in the python
environment.
But I'll keep this in my mind, IFF it comes back to haunt me more.
Thanx,
--WjW
next prev parent reply other threads:[~2016-01-06 10:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-20 16:10 FreeBSD Building and Testing Willem Jan Withagen
2015-12-21 0:45 ` Xinze Chi (信泽)
[not found] ` <CANE=7sU9QPH2uUS8A4xhPQ1j+jR6Fi88=PVvLRGEhzt2cmOceg@mail.gmail.com>
2015-12-21 1:16 ` Fwd: " Xinze Chi (信泽)
2015-12-21 20:14 ` Willem Jan Withagen
2015-12-28 16:53 ` Willem Jan Withagen
2016-01-05 18:23 ` Gregory Farnum
2016-01-06 10:21 ` Willem Jan Withagen [this message]
2016-01-06 7:51 ` Mykola Golub
2016-01-06 10:16 ` Willem Jan Withagen
2016-01-06 12:41 ` Willem Jan Withagen
2015-12-21 23:40 ` 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=568CEAAA.9080602@digiware.nl \
--to=wjw@digiware.nl \
--cc=ceph-devel@vger.kernel.org \
--cc=gfarnum@redhat.com \
--cc=xmdxcxz@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox