<div dir="ltr">I think the dump would be very helpful. I need to know what the overlapped io threads are doing and what values are set in the dp->out struct. <div><br></div><div>Lukas</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Aug 20, 2014 at 3:20 PM, Vlad Dumitrescu <span dir="ltr"><<a href="mailto:vladdu55@gmail.com" target="_blank">vladdu55@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 dir="ltr">Hi Lukas,<div><br></div><div>I was about to send this anyway. Maybe this is enough from the dump? If not i will send the whole of it. You can also see it's R16B03-1, but it's the same for 15 and 17.</div>


<div><br></div><div>The stacktrace is<div><br></div><div><div>0523f644 0f528254 02b40e88 000140cb 02b40d40 beam_smp!fd_stop+0x5a [c:\cygwin\ldisk\daily_build\r16b03-1_opu_c.2014-01-23_17\otp_src_r16b03-1\erts\emulator\sys\win32\sys.c @ 2351]</div>


<div>0523f660 0f529fe5 fffffffb 02b40d40 000140cb beam_smp!terminate_port+0x64 [c:\cygwin\ldisk\daily_build\r16b03-1_opu_c.2014-01-23_17\otp_src_r16b03-1\erts\emulator\beam\io.c @ 3417]</div><div>0523f678 0f52ad53 0000001b 00014607 000140cb beam_smp!erts_deliver_port_exit+0x225 [c:\cygwin\ldisk\daily_build\r16b03-1_opu_c.2014-01-23_17\otp_src_r16b03-1\erts\emulator\beam\io.c @ 3651]</div>


<div>0523f694 0f5cdd99 02b40d40 0f64099c 000000e8 beam_smp!driver_failure_atom+0x93 [c:\cygwin\ldisk\daily_build\r16b03-1_opu_c.2014-01-23_17\otp_src_r16b03-1\erts\emulator\beam\io.c @ 6948]</div><div>0523f6bc 0f543c5d 00000000 0000027c 03700580 beam_smp!ready_output+0xa9 [c:\cygwin\ldisk\daily_build\r16b03-1_opu_c.2014-01-23_17\otp_src_r16b03-1\erts\emulator\sys\win32\sys.c @ 2850]</div>


<div>0523f700 0f53dba4 03700580 0370719c 000007d0 beam_smp!erts_port_task_execute+0x28d [c:\cygwin\ldisk\daily_build\r16b03-1_opu_c.2014-01-23_17\otp_src_r16b03-1\erts\emulator\beam\erl_port_task.c @ 1689]</div><div>0523f740 0f5a9255 03700580 000007d1 02723fe0 beam_smp!schedule+0xb24 [c:\cygwin\ldisk\daily_build\r16b03-1_opu_c.2014-01-23_17\otp_src_r16b03-1\erts\emulator\beam\erl_process.c @ 7065]</div>


<div>0523f790 77bf38aa 00000017 03707100 00000f4b beam_smp!process_main+0x125</div></div><div><br></div><div>And the code is sys.c </div><div><br></div><div><div>static void fd_stop(ErlDrvData data)</div><div>{</div><div>


  DriverData * dp = (DriverData *) data;</div><div>  /*</div><div>   * There's no way we can terminate an fd port in a consistent way.</div><div>   * Instead we let it live until it's opened again (which it is,</div>


<div>   * as the only FD-drivers are for 0,1 and 2 adn the only time they</div><div>   * get closed is by init:reboot).</div><div>   * So - just deselect them and let everything be as is. </div><div>   * They get woken up in fd_start again, where the DriverData is</div>


<div>   * remembered. /PaN</div><div>   */</div><div>  if (dp->in.ov.hEvent != NULL) {</div><div>      (void) driver_select(dp->port_num,</div><div><span style="white-space:pre-wrap">                     </span>   (ErlDrvEvent)dp->in.ov.hEvent,</div>


<div><span style="white-space:pre-wrap">                  </span>   ERL_DRV_READ, 0);</div><div>  }</div><div>  if (dp->out.ov.hEvent != NULL) {</div><div>      (void) driver_select(dp->port_num,</div><div><span style="white-space:pre-wrap">                      </span>   (ErlDrvEvent)dp->out.ov.hEvent,</div>


<div><span style="white-space:pre-wrap">                  </span>   ERL_DRV_WRITE, 0);</div><div>      do {</div><div><span style="white-space:pre-wrap">      </span>ASSERT(dp->out.flushEvent);</div><div><span style="white-space:pre-wrap">   </span>SetEvent(dp->out.flushEvent);</div>


<div>      } while (WaitForSingleObject(dp->out.flushReplyEvent, 10) == WAIT_TIMEOUT </div><div><span style="white-space:pre-wrap">    </span>       || !(dp->out.flags & DF_THREAD_FLUSHED)); // this is line 2351</div>


<div>  }    </div><div><br></div><div>}</div></div><div><br></div><div>The code is not really hung, but it looks like the do/while loop is never exited. (It's possible that there's another loop at a higher level, in any case looking at the stacktrace et different moments it is most often like the one above).</div>


<div><br></div><div>The use case is that the erlang node is started from java and the problem happens when the java process is killed mercilessly. I will try to create a simple test to reproduce this.</div><div><br></div>


<div>regards,</div><div>Vlad</div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Wed, Aug 20, 2014 at 3:08 PM, Lukas Larsson <span dir="ltr"><<a href="mailto:lukas@erlang.org" target="_blank">lukas@erlang.org</a>></span> wrote:<br>


</div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello Vlad,<div><br></div><div>This is most probably a windows only issue as the code in the stacktrace runs through a lot of windows specific code. I guess the easiest way would be if you are able to write a testcase that can reproduce the error so that I can debug it here. If that is not possible, maybe you can attach to the process and send me a windows "core file"?</div>



<div><br></div><div>To do this you have to install WinDbg[1] and then do "File->Attach to a Process". After this you open the WinDbg console and type ".dump /ma c:\beam.smp.dmp" and then upload that file on a server where I can download it. Also I assume you have used one of the installers on <a href="http://erlang.org" target="_blank">erlang.org</a>? Which version of windows+Erlang/OTP are you using?</div>



<div><br></div><div>Lukas</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Wed, Aug 20, 2014 at 11:18 AM, Vlad Dumitrescu <span dir="ltr"><<a href="mailto:vladdu55@gmail.com" target="_blank">vladdu55@gmail.com</a>></span> wrote:<br>



</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Some details: the beam process seems to have a thread that sits and does something. I don't know if the following example stack helps.<div>



<br></div><div>best regards,</div><div>Vlad<br><div><br></div><div>

<div>wow64cpu.dll!TurboDispatchJumpAddressEnd+0x63b</div><div>wow64.dll!Wow64SystemServiceEx+0x1ce</div><div>wow64.dll!Wow64LdrpInitialize+0x42a</div><div>ntdll.dll!RtlIsDosDeviceName_U+0x23a27</div><div>ntdll.dll!LdrInitializeThunk+0xe</div>





</div><div><br></div><div><div>kernel32.dll!SetEvent+0x2</div><div>beam.smp.dll!fd_stop+0x4f</div><div>beam.smp.dll!terminate_port+0x64</div><div>beam.smp.dll!erts_deliver_port_exit+0x225</div><div>beam.smp.dll!driver_failure_atom+0x93</div>





<div>beam.smp.dll!ready_output+0xa9</div><div>beam.smp.dll!erts_port_task_execute+0x28d</div><div>beam.smp.dll!schedule+0xb24</div><div>beam.smp.dll!_process_main+0x125</div><div>ntdll.dll!RtlImageNtHeader+0x716</div><div>





beam.smp.dll!do_erts_alcu_free+0x5f</div><div>beam.smp.dll!erts_alcu_free_thr_spec+0x58</div><div>beam.smp.dll!thr_wrapper+0xa6</div><div>kernel32.dll!BaseThreadInitThunk+0x12</div><div>ntdll.dll!RtlInitializeExceptionChain+0x63</div>





<div>ntdll.dll!RtlInitializeExceptionChain+0x36</div></div><div><br></div></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 20, 2014 at 10:26 AM, Vlad Dumitrescu <span dir="ltr"><<a href="mailto:vladdu55@gmail.com" target="_blank">vladdu55@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 dir="ltr">Hi!<div><br></div><div>I have some nodes that don't want to terminate and that I can't connect to. Most of the times the nodes unregister from epmd, but even when they don't they still are inaccessible.</div>






<div><br></div><div>I was hoping that by connecting to the node I can see why it is hanging, but I get the feeling that the hanging is not inside user code (because epmd detects the socket being closed, so the shutdown process is started).</div>






<div><br></div><div>This is on Windows, but I have some reports for something that looks similar from Linux too.</div><div>I'm not used to debugging this kind of situations, so I hope that someone has some advice for me. </div>






<div><br></div><div>best regards,</div><div>Vlad</div><div><br><div><br></div><div><br></div></div></div>
</blockquote></div><br></div>
</div></div><br></div></div>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div></div><br></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>