The frame which you used for doing the STACK_WIND(create) was probably unwound by the time the create_cbk came back from the server? This is the most common/likely cause..<div><br></div><div>Avati<br><br><div class="gmail_quote">
On Thu, Oct 11, 2012 at 1:59 PM, Gustavo Bervian Brand <span dir="ltr"><<a href="mailto:gugabrand@gmail.com" target="_blank">gugabrand@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Hello,</div><div><br></div><div> I gave up of using syncop calls at my attempt of copy a file to a local node while the read is happening (at each readv_cbk in this case)... it was failing often and I could not benefit from the frame->local isolation between the readv/readv_cbk/<syncop calls> because the local context was lost when inside the function called by synctask_new.</div>
<div><br></div><div> Anyway, I built a logic with wind/unwind calls instead, and I am getting a strange fault to begin with, out of my translator. At the readv_cbk() I am calling xl->fops->create with most of the parameters I was using with syncop_create (the fd, loc, flags, etc were created and populated locally while in the readv_cbk), but the execution is stopping at the path below because the <b>myframe->local is NULL</b> and the fd cannot be gathered <b>at client3_3_create_cbk().</b></div>
<div><br></div><div> <b>At the backend the file was created</b> (but not yet populated or set with attributes). </div><div> Does this kind of behavior is known, a bug for an unusual scenario, or what I am missing here?</div>
<br><div>Program received signal SIGSEGV, Segmentation fault.</div><div>0x00007ffff3bc964f in <b>client3_3_create_cbk</b> (req=0x7ffff36751a4, iov=0x7ffff36751e4, count=1, myframe=0x7ffff5dcb2dc) at client-rpc-fops.c:2008</div>
<div>2008 fd = local->fd;</div><div>(gdb)</div><div>(gdb) bt</div><div>#0 0x00007ffff3bc964f in client3_3_create_cbk (req=0x7ffff36751a4, iov=0x7ffff36751e4, count=1, myframe=0x7ffff5dcb2dc) at client-rpc-fops.c:2008</div>
<div>#1 0x00007ffff7944e8b in rpc_clnt_handle_reply (clnt=0x693860, pollin=0x6e5d80) at rpc-clnt.c:784</div><div>#2 0x00007ffff79451fc in rpc_clnt_notify (trans=0x6a3290, mydata=0x693890, event=RPC_TRANSPORT_MSG_RECEIVED, data=0x6e5d80) at rpc-clnt.c:903</div>
<div>#3 0x00007ffff79416bb in rpc_transport_notify (this=0x6a3290, event=RPC_TRANSPORT_MSG_RECEIVED, data=0x6e5d80) at rpc-transport.c:495</div><div>#4 0x00007ffff3466e20 in socket_event_poll_in (this=0x6a3290) at socket.c:1986</div>
<div>#5 0x00007ffff34672bd in socket_event_handler (fd=14, idx=1, data=0x6a3290, poll_in=1, poll_out=0, poll_err=0) at socket.c:2097</div><div>#6 0x00007ffff7b98fce in event_dispatch_epoll_handler (event_pool=0x6505e0, events=0x6c9c90, i=0) at event.c:784</div>
<div>#7 0x00007ffff7b991ad in event_dispatch_epoll (event_pool=0x6505e0) at event.c:845</div><div>#8 0x00007ffff7b99494 in event_dispatch (event_pool=0x6505e0) at event.c:945</div><div>#9 0x0000000000408ae0 in main (argc=7, argv=0x7fffffffe568) at glusterfsd.c:1814</div>
<br>Best,<br>Gustavo Bervian Brand<br>---------------------------------------------------------------------------------<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>
<br></blockquote></div><br></div>