We haven&#39;t come across this issue so far.. can you post the complete backtrace from your debugger?<div><br></div><div>Avati<br><br><div class="gmail_quote">On Sun, Jul 3, 2011 at 1:21 PM, Emmanuel Dreyfus <span dir="ltr">&lt;<a href="mailto:manu@netbsd.org">manu@netbsd.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi<br>
<br>
I get a reprodcutbile crash of glusterfsd, running 3.2.1 code. I get it<br>
by running multiple tar -xzf on a client, and after a while, a<br>
glusterfsd on a brick crashes:<br>
<br>
Program terminated with signal 11, Segmentation fault.<br>
#0  0xba0d652e in server_rchecksum_cbk (frame=0xbad007d0,<br>
    cookie=0xbaf00300, this=0xba810000, op_ret=-1, op_errno=9,<br>
    weak_checksum=0, strong_checksum=0xb91ffc74 &quot;&quot;) at<br>
    server3_1-fops.c:1305<br>
<br>
Here is the offending code<br>
<br>
        if (op_ret == -1)<br>
                gf_log (this-&gt;name, GF_LOG_INFO,<br>
                        &quot;%&quot;PRId64&quot;: RCHECKSUM %&quot;PRId64&quot; (%&quot;PRId64&quot;) ==&gt;<br>
%&quot;PRId32&quot; (%s)&quot;,<br>
                        frame-&gt;root-&gt;unique, state-&gt;resolve.fd_no,<br>
                        state-&gt;fd ? state-&gt;fd-&gt;inode-&gt;ino : 0, op_ret,<br>
                        strerror (op_errno));<br>
<br>
The problem is state-&gt;fd-&gt;inode value:<br>
<br>
(gdb) print *((server_state_t *)frame-&gt;root-&gt;state)-&gt;fd<br>
$7 = {pid = 2610, flags = 2, refcount = 2, inode_list =<br>
        {next = 0xb9801088, prev = 0xb9801088}, inode = 0xaaaaaaaa,<br>
        lock = {pts_magic = 3735879687, pts_spin = 0 &#39;\0&#39;, pts_flags =<br>
        0}, _ctx = 0xbb96b080, xl_count = 8}<br>
<br>
inode = 0xaaaaaaaa is set in fd_destroy() to denote a stale object (It<br>
is less fun than using 0xdeadbeef :-)<br>
<br>
That suggests a race condition where a thread uses a fd that another<br>
thread destroyed. Of course, the value could be checked at the beginning<br>
of server_rchecksum_cbk(), but I suspect the problem is more widespread<br>
that this. There are many other places in server3_1-fops.c where<br>
state-&gt;fd-&gt;inode-&gt;ino is used.<br>
<br>
And should the value be checked at the beginning of<br>
server_rchecksum_cbk() and its friends, or in any gf_log() call, like<br>
this:<br>
        if (op_ret == -1)<br>
                gf_log (this-&gt;name, GF_LOG_INFO,<br>
                        &quot;%&quot;PRId64&quot;: RCHECKSUM %&quot;PRId64&quot; (%&quot;PRId64&quot;) &quot;<br>
                        &quot;==&gt; %&quot;PRId32&quot; (%s)&quot;,<br>
                        frame-&gt;root-&gt;unique, state-&gt;resolve.fd_no,<br>
                        state-&gt;fd &amp;&amp; (state-&gt;fd-&gt;inode != 0xaaaaaaaa) ?<br>
                        state-&gt;fd-&gt;inode-&gt;ino : 0, op_ret,<br>
                        strerror (op_errno));<br>
<br>
FWIW this is a 2x2 replicated and distributed setup.<br>
<br>
--<br>
Emmanuel Dreyfus<br>
<a href="http://hcpnet.free.fr/pubz" target="_blank">http://hcpnet.free.fr/pubz</a><br>
<a href="mailto:manu@netbsd.org">manu@netbsd.org</a><br>
<br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a><br>
<a href="https://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
</blockquote></div><br></div>