[Gluster-devel] Synctask memory corruption in NetBSD

[Manikandan Selvaganesh]

Hi,

There are some quota related tests that are failing in NetBSD. We had a
look at the core files that the test has generated. Apparently, it is
failing in synctask framework. Marker uses synctask framework a lot and the
stack size that we use in marker is 16k. Here is the stack trace:

#0  0xbb4104b7 in ?? ()
(gdb) bt
#0  0xbb4104b7 in ?? ()
#1  0xbb410458 in ?? ()
#2  0x0004 in ?? ()
#3  0x0006 in ?? ()
#4  0xbb457084 in ?? ()
#5  0xbb759119 in synctask_destroy (task=0xb8a18030) at
/home/jenkins/root/workspace/rackspace-netbsd7-regression-triggered/libglusterfs/src/syncop.c:391
#6  0xbb759195 in synctask_done (task=0xb8a18030) at
/home/jenkins/root/workspace/rackspace-netbsd7-regression-triggered/libglusterfs/src/syncop.c:409
#7  0xbb759a81 in synctask_switchto (task=0xb8a18030) at
/home/jenkins/root/workspace/rackspace-netbsd7-regression-triggered/libglusterfs/src/syncop.c:668
#8  0xbb759b2f in syncenv_processor (thdata=, thdata@entry=)
at 
/home/jenkins/root/workspace/rackspace-netbsd7-regression-triggered/libglusterfs/src/syncop.c:699


Here[1] are the bugs filed which can give more information on the
failed NetBSD regressions. Could you please have a look on this issue?


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1332045

https://bugzilla.redhat.com/show_bug.cgi?id=1332021

https://bugzilla.redhat.com/show_bug.cgi?id=1332020


-- 
Thanks & Regards,
Manikandan Selvaganesh.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Synctask memory corruption in NetBSD

[Emmanuel Dreyfus]

Manikandan Selvaganesh  wrote:

> #0  0xbb4104b7 in ?? ()
> (gdb) bt
> #0  0xbb4104b7 in ?? ()
> #1  0xbb410458 in ?? ()
> #2  0x0004 in ?? ()
> #3  0x0006 in ?? ()
> #4  0xbb457084 in ?? ()
> #5  0xbb759119 in synctask_destroy (task=0xb8a18030) at

In my opinion there is no particular reason it should be related to
synctask: the stack is obviously corupted (0x0004 is certainly
wrong), and we cannot trust what is below.

I do not say it cannot be in synctask, but it could be anywhere. Do you
have any hint about where the thread last executed known code?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel