Emmanuel Dreyfus m...@netbsd.org wrote:
Regarding NetBSD AFR regression: I tracked it down to memory corruption
on iobuf-iobrefs, where at some point I get iobuf-iobrefs[0] == 3,
which is not a sane value for a pointer. Surrounding memory also get
small uint8 values.
(...)
I have not been
On Mon, Mar 23, 2015 at 01:51:07PM +0100, Emmanuel Dreyfus wrote:
I have ran out of smart ideas, and now I am going to start from older
master and add commits to find the offending one. Any better idea is
welcome.
git bissect points a finger to this change:
http://review.gluster.org/9708/
There are other instances where iobuf_arena-page_size is used in
iobuf.c and there are about a dozen callers for iobuf_size(). There
needs to be something fishy about the call in the patch you mention to
trigger the overrun.
On Mon, Mar 23, 2015 at 10:59 PM, Emmanuel Dreyfus m...@netbsd.org
Is there some way to put guards/checks in this bit of code to log
the callers + their arguments somewhere and then stand back to watch
it crash? And figure it out from there?
Kinda guessing you guys are way past that though...
+ Justin
On 23 Mar 2015, at 17:39, Venky Shankar
Venky Shankar yknev.shan...@gmail.com wrote:
There are other instances where iobuf_arena-page_size is used in
iobuf.c and there are about a dozen callers for iobuf_size(). There
needs to be something fishy about the call in the patch you mention to
trigger the overrun.
Logging the values
