On Sat, Jul 29, 2017 at 4:42 AM, Gregory Farnum <gfarnum@xxxxxxxxxx> wrote:
> ________________________________________________________________________________________________________
>> *** CID 1415755: Memory - corruptions (OVERRUN)
>> /home/brad/working/src/ceph/src/mon/MonCommand.h: 39 in MonCommand::encode(ceph::buffer::list &) const()
>> 33
>> 34 bool has_flag(uint64_t flag) const { return (flags & flag) != 0; }
>> 35 void set_flag(uint64_t flag) { flags |= flag; }
>> 36 void unset_flag(uint64_t flag) { flags &= ~flag; }
>> 37
>> 38 void encode(bufferlist &bl) const {
>>>>> CID 1415755: Memory - corruptions (OVERRUN)
>>>>> Overrunning struct type ceph_le32 of 4 bytes by passing it to a function which accesses it at byte offset 7.
>> 39 ENCODE_START(1, 1, bl);
>> 40 encode_bare(bl);
>> 41 ::encode(flags, bl);
>> 42 ENCODE_FINISH(bl);
>> 43 }
>> 44
>
> I looked at this one briefly and don't understand it at all. The only
> ceph_le32 I can find related to it is the struct_v (defined in the
> macro), and there's nothing referencing it oddly! Anybody have some
> idea?
We could try compiling with "-fsanitize=address" and exercise this code then try
it under valgrind (I imagine this is already done since this code is well used).
If neither of those show up the problem we could probably flag it as a false
positive?
> -Greg
> --
> 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
--
Cheers,
Brad
--
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
