https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112010-07-12T19:55:22ZRuby Issue Tracking SystemRuby master - Bug #3523: win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/3523?journal_id=122872010-07-12T19:55:22Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>3</i></li></ul><p>=begin<br>
Hi,</p>
<p>2010/7/2 B Kelly <a href="mailto:redmine@ruby-lang.org" class="email">redmine@ruby-lang.org</a>:</p>
<blockquote>
<p>I'm encountering a windows exception c0000029 crash when my application (which uses fibers) runs on v1.9.2. ?The program runs to completion, and its tests all pass, but the exception occurs when ruby exits.</p>
<p>So far the crash happens consistently on v1.9.2-dev, but never happens on trunk (1.9.3-dev).</p>
<p>I will attempt to isolate a small bit of code which reproduces the problem. ?But I wanted to post in the meantime in case anyone might have ideas about what could cause this exception, or why it might differ between 1.9.2 and trunk.</p>
</blockquote>
<p>What's going on?</p>
<p>Indeed, this looks like core's bug. But we can't do anything unless<br>
there is reproducible code. Meanwhile, I set the priority to Low.<br>
If you could create code that you can disclose, please reply to this<br>
thread.</p>
<p>--<br>
Yusuke Endoh <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a><br>
=end</p> Ruby master - Bug #3523: win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/3523?journal_id=122962010-07-13T04:09:32Zspatulasnout (B Kelly)billk@cts.com
<ul></ul><p>=begin<br>
Hi,</p>
<p>Yusuke Endoh wrote:</p>
<blockquote>
<p>What's going on?</p>
<p>Indeed, this looks like core's bug. But we can't do anything unless<br>
there is reproducible code. Meanwhile, I set the priority to Low.<br>
If you could create code that you can disclose, please reply to this<br>
thread.</p>
</blockquote>
<p>Sorry for the delay.</p>
<p>Last week I made several attempts to create smaller sample<br>
programs which reproduced the error. To my surprise, the<br>
smaller programs fail to produce the error, but the larger<br>
program still gets the error EVERY time.</p>
<p>Here is what I have learned so far:</p>
<ol>
<li>
<p>The 0xc0000029 exception apparently means:<br>
"An invalid unwind target was encountered during an unwind<br>
operation."</p>
</li>
<li>
<p>I suspect the error may have something to do with having<br>
a C++ stack frame when switching fibers. I am using<br>
EventMachine, and changing fibers on the event callback.</p>
</li>
</ol>
<p>Example:</p>
<p>EM-fiber: callback into ruby (with C++ stack frame)<br>
transfer to Dispatch-fiber<br>
transfer back to EM-fiber<br>
return</p>
<p>But again, I can't reproduce the error with a program<br>
as simple as the above.</p>
<ol start="3">
<li>
<p>I have back-ported the "cont.c" from trunk to 1.9.2, and<br>
the 0xc0000029 problem disappears.</p>
</li>
<li>
<p>Apparently cont.c from trunk uses FIBER_USE_NATIVE, which<br>
was briefly in 1.9.2, but was reverted.</p>
</li>
</ol>
<p>That is all I know, so far.</p>
<p>By the way, I was interested to learn the reason why<br>
FIBER_USE_NATIVE was reverted in 1.9.2. I think the<br>
following discussion may contain the answer, but,<br>
Google Translate was not very helpful:</p>
<p><a href="http://redmine.ruby-lang.org/issues/show/3295" class="external">http://redmine.ruby-lang.org/issues/show/3295</a></p>
<p>If possible, could anyone who understands Japanese<br>
please summarize the reason for the revert in<br>
English?</p>
<p>Meanwhile, I will make another attempt to reduce<br>
the amount of code needed to reproduce the problem,<br>
in the next couple days.</p>
<p>Thanks,</p>
<p>Bill</p>
<p>=end</p> Ruby master - Bug #3523: win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/3523?journal_id=123172010-07-13T22:02:21Zluislavena (Luis Lavena)luislavena@gmail.com
<ul></ul><p>=begin<br>
On Mon, Jul 12, 2010 at 4:09 PM, B Kelly <a href="mailto:redmine@ruby-lang.org" class="email">redmine@ruby-lang.org</a> wrote:</p>
<blockquote>
<p>Sorry for the delay.</p>
<p>Last week I made several attempts to create smaller sample<br>
programs which reproduced the error. To my surprise, the<br>
smaller programs fail to produce the error, but the larger<br>
program still gets the error EVERY time.</p>
<p>Here is what I have learned so far:</p>
<ol>
<li>
<p>The 0xc0000029 exception apparently means:<br>
"An invalid unwind target was encountered during an unwind<br>
operation."</p>
</li>
<li>
<p>I suspect the error may have something to do with having<br>
a C++ stack frame when switching fibers. I am using<br>
EventMachine, and changing fibers on the event callback.</p>
</li>
</ol>
</blockquote>
<p>Is EventMachine compiled with the same Visual C?</p>
<p>I can see EventMachine 0.12.10 compiled for Visual C 6.0, so if you<br>
haven't forced it, it should not install that version and instead<br>
compile it for you.</p>
<p>EventMachine binary gem might have been compiled with MinGW, Since it<br>
uses C++, unwind stacks are different and could be the root of the<br>
failure.</p>
<h2>--<br>
Luis Lavena<br>
AREA 17</h2>
<p>Perfection in design is achieved not when there is nothing more to add,<br>
but rather when there is nothing more to take away.<br>
Antoine de Saint-Exupéry</p>
<p>=end</p> Ruby master - Bug #3523: win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/3523?journal_id=123182010-07-13T22:22:51Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>=begin<br>
Hi,</p>
<p>2010/7/13 B Kelly <a href="mailto:redmine@ruby-lang.org" class="email">redmine@ruby-lang.org</a>:</p>
<blockquote>
<p>By the way, I was interested to learn the reason why<br>
FIBER_USE_NATIVE was reverted in 1.9.2. ?I think the<br>
following discussion may contain the answer, but,<br>
Google Translate was not very helpful:</p>
<p><a href="http://redmine.ruby-lang.org/issues/show/3295" class="external">http://redmine.ruby-lang.org/issues/show/3295</a></p>
<p>If possible, could anyone who understands Japanese<br>
please summarize the reason for the revert in<br>
English?</p>
</blockquote>
<p>FIBER_USE_NATIVE patch aims to improve performance of fiber by using<br>
platform-specific fiber feature (such as win32 fiber, getcontext, etc)<br>
if available.<br>
But the approach requires many experiences in various platform.<br>
Actually, it caused assert error on Ubuntu, so we determined the patch<br>
was too premature for 1.9.2.</p>
<blockquote>
<p>Meanwhile, I will make another attempt to reduce<br>
the amount of code needed to reproduce the problem,<br>
in the next couple days.</p>
</blockquote>
<p>Good luck!</p>
<p>--<br>
Yusuke Endoh <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a></p>
<p>=end</p> Ruby master - Bug #3523: win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/3523?journal_id=123362010-07-14T07:16:07Zspatulasnout (B Kelly)billk@cts.com
<ul></ul><p>=begin<br>
Hi,</p>
<p>Luis Lavena wrote:</p>
<blockquote>
<p>Is EventMachine compiled with the same Visual C?</p>
</blockquote>
<p>Yes, all extensions are compiled locally, in this<br>
case with cl.exe from Visual Studio 2010 (version<br>
16.00.30319.01).</p>
<p>EventMachine was pulled from git on 2010-06-16</p>
<p>Regards,</p>
<p>Bill</p>
<p>=end</p> Ruby master - Bug #3523: win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/3523?journal_id=123622010-07-15T21:45:44Zspatulasnout (B Kelly)billk@cts.com
<ul><li><strong>File</strong> <a href="/attachments/1104">test_em_fiber4f.rb</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1104/test_em_fiber4f.rb">test_em_fiber4f.rb</a> added</li></ul><p>=begin<br>
Hi,</p>
<p>I've attached a program (in redmine) which reproduces<br>
the c0000029 crash on ruby_1_9_2 / Windows 7.</p>
<p>The program is a single source file, but it does<br>
depend on the EventMachine extension.</p>
<p>The crash happens every time for me. There are<br>
comments at the top of the source file explaining how<br>
EventMachine was built, and describing lines which<br>
can be added or removed to alter or prevent the<br>
c0000029 from occurring.</p>
<p>I'm using Visual Studio 2010 to compile both ruby<br>
and EventMachine.</p>
<p>If there's any way I can help please let me know.</p>
<p>Thanks,</p>
<p>Bill</p>
<p>=end</p> Ruby master - Bug #3523: win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/3523?journal_id=123682010-07-16T10:25:35Zusa (Usaku NAKAMURA)usa@garbagecollect.jp
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Assigned</i></li><li><strong>Assignee</strong> set to <i>usa (Usaku NAKAMURA)</i></li></ul><p>=begin<br>
I'm tracking this ticket now.<br>
Thank you, Bill! (and of course, Luis and Endoh-san!)</p>
<p>Now I'm doubting that the occasion is that SEH frame is not replaced<br>
when the stack is replaced with fiber switch.<br>
The implementation of Thread of 1.8 has this replacement, but it<br>
seems to have been forgotten in Fiber of 1.9.2...</p>
<p>=end</p> Ruby master - Bug #3523: win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/3523?journal_id=123702010-07-16T12:57:46Zusa (Usaku NAKAMURA)usa@garbagecollect.jp
<ul></ul><p>=begin<br>
Hello,</p>
<blockquote>
<p><a href="http://redmine.ruby-lang.org/issues/show/3523" class="external">http://redmine.ruby-lang.org/issues/show/3523</a></p>
</blockquote>
<p>Interim report:</p>
<p>There is a patch for ruby_1_9_2, to save and restore SEH frame.<br>
After this patch is applied, Bill's 0xC0000029 error vanishes!</p>
<h1>... But another error 0xC0000374 occurs.<br>
This error means heap corruption.<br>
I cannot confirm yet whether this error is due to ruby or EventMachine.<br>
<br>
Index: cont.c</h1>
<p>--- cont.c (revision 28653)<br>
+++ cont.c (working copy)<br>
@@ -39,6 +39,9 @@ typedef struct rb_context_struct {<br>
VALUE *machine_register_stack_src;<br>
int machine_register_stack_size;<br>
#endif<br>
+#if _WIN32 && (defined(_M_IX86) || defined(<strong>i386</strong>))</p>
<ul>
<li>VALUE win32_exception_list;<br>
+#endif<br>
rb_thread_t saved_thread;<br>
rb_jmpbuf_t jmpbuf;<br>
size_t machine_stack_size;<br>
@@ -224,6 +227,44 @@ fiber_memsize(const void *ptr)<br>
return 0;<br>
}</li>
</ul>
<p>+#if _WIN32 && (defined(_M_IX86) || defined(<strong>i386</strong>))<br>
+static inline VALUE<br>
+win32_get_exception_list(void)<br>
+{</p>
<ul>
<li>VALUE p;<br>
+# if defined _MSC_VER<br>
+# ifdef _M_IX86<br>
+# if _MSC_VER >= 1310</li>
<li>
<pre><code> /* warning: unsafe assignment to fs:0 ... this is ok */
</code></pre>
</li>
</ul>
<p>+# pragma warning(disable: 4733)<br>
+# endif</p>
<ul>
<li>__asm mov eax, fs:[0];</li>
<li>__asm mov p, eax;<br>
+# endif<br>
+# elif defined <strong>GNUC</strong><br>
+# ifdef <strong>i386</strong>
</li>
<li>
<strong>asm</strong>("movl %%fs:0,%0" : "=r"(p));<br>
+# endif<br>
+# endif</li>
<li>return p;<br>
+}</li>
<li>
</ul>
<p>+static inline void<br>
+win32_set_exception_list(VALUE p)<br>
+{<br>
+# if defined _MSC_VER<br>
+# ifdef _M_IX86</p>
<ul>
<li>__asm mov eax, p;</li>
<li>__asm mov fs:[0], eax;<br>
+# endif<br>
+# elif defined <strong>GNUC</strong><br>
+# ifdef <strong>i386</strong>
</li>
<li>
<strong>asm</strong>("movl %0,%%fs:0" :: "r"(p));<br>
+# endif<br>
+# endif<br>
+}<br>
+#endif</li>
<li>
</ul>
<p>static void<br>
cont_save_machine_stack(rb_thread_t *th, rb_context_t *cont)<br>
{<br>
@@ -267,6 +308,9 @@ cont_save_machine_stack(rb_thread_t *th,</p>
<pre><code> MEMCPY(cont->machine_register_stack, cont->machine_register_stack_src, VALUE, size);
</code></pre>
<p>#endif<br>
+#if _WIN32 && (defined(_M_IX86) || defined(<strong>i386</strong>))</p>
<ul>
<li>
<p>cont->win32_exception_list = win32_get_exception_list();<br>
+#endif</p>
<p>sth->machine_stack_start = sth->machine_stack_end = 0;<br>
#ifdef __ia64<br>
@@ -403,6 +447,9 @@ cont_restore_1(rb_context_t *cont)<br>
}<br>
#endif<br>
if (cont->machine_stack_src) {<br>
+#if _WIN32 && (defined(_M_IX86) || defined(<strong>i386</strong>))</p>
</li>
<li>
<p>win32_set_exception_list(cont->win32_exception_list);<br>
+#endif<br>
FLUSH_REGISTER_WINDOWS;<br>
MEMCPY(cont->machine_stack_src, cont->machine_stack,<br>
VALUE, cont->machine_stack_size);<br>
<br>
Regards,<br>
--<br>
U.Nakamura <a href="mailto:usa@garbagecollect.jp" class="email">usa@garbagecollect.jp</a></p>
</li>
</ul>
<p>=end</p> Ruby master - Bug #3523: win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/3523?journal_id=123732010-07-16T19:50:17Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul><li><strong>Priority</strong> changed from <i>3</i> to <i>Normal</i></li></ul><p>=begin</p>
<p>=end</p> Ruby master - Bug #3523: win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/3523?journal_id=123822010-07-17T04:14:52Zspatulasnout (B Kelly)billk@cts.com
<ul></ul><p>=begin<br>
Hi,</p>
<p>U.Nakamura wrote:</p>
<blockquote>
<p>Interim report:</p>
<p>There is a patch for ruby_1_9_2, to save and restore SEH frame.<br>
After this patch is applied, Bill's 0xC0000029 error vanishes!</p>
<p>... But another error 0xC0000374 occurs.<br>
This error means heap corruption.<br>
I cannot confirm yet whether this error is due to ruby or EventMachine.</p>
</blockquote>
<p>Thank you. I've applied the patch, and I initially saw<br>
the 0xC0000374 error, too.</p>
<p>Then I installed some Memory Validator software [1] to<br>
try to learn more (which I have a license for, but had<br>
never installed on my new OS).</p>
<p>However, I am not able to reproduce the 0xC0000374<br>
anymore. With or without Memory Validator running, nor<br>
from the shell, nor within Visual Studio's debugger.<br>
The 0xC0000374 seems to have suddenly disappeared, but,<br>
I have not changed or recompiled anything, as far as I<br>
know! :(</p>
<p>Are you still seeing the 0xC0000374 on your end?</p>
<p>Regards,</p>
<p>Bill</p>
<p>[1] <a href="http://www.softwareverify.com/cpp/memory/index.html" class="external">http://www.softwareverify.com/cpp/memory/index.html</a></p>
<p>=end</p> Ruby master - Bug #3523: win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/3523?journal_id=123962010-07-17T21:56:29Zspatulasnout (B Kelly)billk@cts.com
<ul></ul><p>=begin<br>
Bill Kelly wrote:</p>
<blockquote>
<p>However, I am not able to reproduce the 0xC0000374<br>
anymore.</p>
</blockquote>
<p>Very strange. I put the test in a loop, i.e.:</p>
<p>def test_em_fiber<br>
GC.stress = true<br>
10.times {do_test_em_fiber}<br>
end</p>
<p>... and now the 0xC0000374 happens again, every time,<br>
after the FIRST time through the loop.</p>
<p>(I already had the GC.stress = true, before.)</p>
<p>Currently MemoryValidator isn't helping much. I will<br>
try recompiling with --enable-shared . . . .</p>
<p>Regards,</p>
<p>Bill</p>
<p>=end</p> Ruby master - Bug #3523: win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/3523?journal_id=124112010-07-19T18:30:36Zspatulasnout (B Kelly)billk@cts.com
<ul></ul><p>=begin<br>
Hi,</p>
<p>Bill Kelly wrote:</p>
<blockquote>
<p>... and now the 0xC0000374 happens again, every time,<br>
after the FIRST time through the loop.</p>
<p>(I already had the GC.stress = true, before.)</p>
<p>Currently MemoryValidator isn't helping much. I will<br>
try recompiling with --enable-shared . . . .</p>
</blockquote>
<p>(Note: --enable-shared didn't change the Makefile produced<br>
by extconf.rb at all. So, nevermind --enable-shared.)</p>
<p>When I put the test in a loop, and if I don't get the<br>
0xC0000374, I see the following:</p>
<pre><code>test/test_em_fiber4f.rb:151: [BUG] Segmentation fault
ruby 1.9.2dev (2010-07-15) [i386-mswin32_100]
-- control frame ----------
c:0025 p:---- s:0096 b:0096 l:000095 d:000095 CFUNC :transfer
c:0024 p:0046 s:0093 b:0093 l:0024f0 d:0024f0 METHOD test/test_em_fiber4f.rb:151
c:0023 p:0083 s:0087 b:0087 l:00265c d:00265c METHOD test/test_em_fiber4f.rb:260
c:0022 p:0076 s:0080 b:0080 l:000079 d:000079 METHOD test/test_em_fiber4f.rb:241
c:0021 p:0021 s:0076 b:0076 l:000075 d:000075 METHOD test/test_em_fiber4f.rb:182
c:0020 p:---- s:0072 b:0072 l:000071 d:000071 FINISH
c:0019 p:---- s:0070 b:0070 l:000069 d:000069 CFUNC :run_machine
c:0018 p:0248 s:0067 b:0067 l:000066 d:000066 METHOD m:/dev/ruby-build/v1_9_2-pure/lib/ruby/site_ruby/1.9.1/eventmachine.rb:195
c:0017 p:0131 s:0060 b:0060 l:001df4 d:001df4 METHOD test/test_em_fiber4f.rb:527
c:0016 p:0009 s:0055 b:0055 l:000047 d:000054 BLOCK test/test_em_fiber4f.rb:512
c:0015 p:---- s:0053 b:0053 l:000052 d:000052 FINISH
c:0014 p:---- s:0051 b:0051 l:000050 d:000050 CFUNC :times
c:0013 p:0030 s:0048 b:0048 l:000047 d:000047 METHOD test/test_em_fiber4f.rb:512
c:0012 p:0063 s:0045 b:0045 l:000044 d:000044 METHOD m:/dev/ruby-build/v1_9_2-pure/lib/ruby/1.9.1/minitest/unit.rb:680
c:0011 p:0091 s:0039 b:0039 l:000020 d:000038 BLOCK m:/dev/ruby-build/v1_9_2-pure/lib/ruby/1.9.1/minitest/unit.rb:641
c:0010 p:---- s:0034 b:0034 l:000033 d:000033 FINISH
c:0009 p:---- s:0032 b:0032 l:000031 d:000031 CFUNC :each
c:0008 p:0026 s:0029 b:0029 l:000020 d:000028 BLOCK m:/dev/ruby-build/v1_9_2-pure/lib/ruby/1.9.1/minitest/unit.rb:635
c:0007 p:---- s:0026 b:0026 l:000025 d:000025 FINISH
c:0006 p:---- s:0024 b:0024 l:000023 d:000023 CFUNC :each
c:0005 p:0082 s:0021 b:0021 l:000020 d:000020 METHOD m:/dev/ruby-build/v1_9_2-pure/lib/ruby/1.9.1/minitest/unit.rb:634
c:0004 p:0188 s:0016 b:0016 l:000015 d:000015 METHOD m:/dev/ruby-build/v1_9_2-pure/lib/ruby/1.9.1/minitest/unit.rb:594
c:0003 p:0041 s:0007 b:0007 l:00212c d:000006 BLOCK m:/dev/ruby-build/v1_9_2-pure/lib/ruby/1.9.1/minitest/unit.rb:492
c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH
c:0001 p:0000 s:0002 b:0002 l:00060c d:00060c TOP
---------------------------
-- Ruby level backtrace information ----------------------------------------
m:/dev/ruby-build/v1_9_2-pure/lib/ruby/1.9.1/minitest/unit.rb:492:in `block in autorun'
m:/dev/ruby-build/v1_9_2-pure/lib/ruby/1.9.1/minitest/unit.rb:594:in `run'
m:/dev/ruby-build/v1_9_2-pure/lib/ruby/1.9.1/minitest/unit.rb:634:in `run_test_suites'
m:/dev/ruby-build/v1_9_2-pure/lib/ruby/1.9.1/minitest/unit.rb:634:in `each'
m:/dev/ruby-build/v1_9_2-pure/lib/ruby/1.9.1/minitest/unit.rb:635:in `block in run_test_suites'
m:/dev/ruby-build/v1_9_2-pure/lib/ruby/1.9.1/minitest/unit.rb:635:in `each'
m:/dev/ruby-build/v1_9_2-pure/lib/ruby/1.9.1/minitest/unit.rb:641:in `block (2 levels) in run_test_suites'
m:/dev/ruby-build/v1_9_2-pure/lib/ruby/1.9.1/minitest/unit.rb:680:in `run'
test/test_em_fiber4f.rb:512:in `test_em_fiber'
test/test_em_fiber4f.rb:512:in `times'
test/test_em_fiber4f.rb:512:in `block in test_em_fiber'
test/test_em_fiber4f.rb:527:in `do_test_em_fiber'
m:/dev/ruby-build/v1_9_2-pure/lib/ruby/site_ruby/1.9.1/eventmachine.rb:195:in `run'
m:/dev/ruby-build/v1_9_2-pure/lib/ruby/site_ruby/1.9.1/eventmachine.rb:195:in `run_machine'
test/test_em_fiber4f.rb:182:in `receive_data'
test/test_em_fiber4f.rb:241:in `rpc_connection_established'
test/test_em_fiber4f.rb:260:in `rpc_dispatch'
test/test_em_fiber4f.rb:151:in `run_in_fiber'
test/test_em_fiber4f.rb:151:in `transfer'
[NOTE]
You may have encountered a bug in the Ruby interpreter or extension libraries.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html
</code></pre>
<p>Note, I get no such crash on 1.9.2 if I back-port cont.c from trunk.<br>
(I can loop the test hundreds of times with no crash.)</p>
<p>So I can't prove it's not EventMachine's fault, but... It seems to<br>
have to do with cont.c.</p>
<p>Regards,</p>
<p>Bill</p>
<p>=end</p> Ruby master - Bug #3523: win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/3523?journal_id=124222010-07-20T15:12:06Zusa (Usaku NAKAMURA)usa@garbagecollect.jp
<ul></ul><p>=begin<br>
Hello,</p>
<p>In message "<a href="https://blade.ruby-lang.org/ruby-core/31351">[ruby-core:31351]</a> Re: [Bug <a class="issue tracker-1 status-8 priority-4 priority-default closed" title="Bug: win32 exception c0000029 on exit using fibers (Third Party's Issue)" href="https://bugs.ruby-lang.org/issues/3523">#3523</a>][Assigned] win32 exception c0000029 on exit using fibers"<br>
on Jul.19,2010 18:30:23, <a href="mailto:billk@cts.com" class="email">billk@cts.com</a> wrote:</p>
<blockquote>
<p>When I put the test in a loop, and if I don't get the<br>
0xC0000374, I see the following:</p>
<pre><code>test/test_em_fiber4f.rb:151: [BUG] Segmentation fault
ruby 1.9.2dev (2010-07-15) [i386-mswin32_100]
</code></pre>
</blockquote>
<p>Great!<br>
Now I can pay attention only to implementation of transfer<br>
method.</p>
<p>Thus, I have not found the cause yet.<br>
From the phenomenon and the point of the problem, it seems that<br>
restoring the stack is a front runner...</p>
<a name="Regards"></a>
<h2 >Regards,<a href="#Regards" class="wiki-anchor">¶</a></h2>
<p>U.Nakamura <a href="mailto:usa@garbagecollect.jp" class="email">usa@garbagecollect.jp</a></p>
<p>=end</p> Ruby master - Bug #3523: win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/3523?journal_id=124502010-07-21T18:31:30Zusa (Usaku NAKAMURA)usa@garbagecollect.jp
<ul></ul><p>=begin<br>
Hello,</p>
<p>In message "<a href="https://blade.ruby-lang.org/ruby-core/31366">[ruby-core:31366]</a> Re: [Bug <a class="issue tracker-1 status-8 priority-4 priority-default closed" title="Bug: win32 exception c0000029 on exit using fibers (Third Party's Issue)" href="https://bugs.ruby-lang.org/issues/3523">#3523</a>][Assigned] win32 exception c0000029 on exit using fibers"<br>
on Jul.20,2010 15:11:56, <a href="mailto:usa@garbagecollect.jp" class="email">usa@garbagecollect.jp</a> wrote:</p>
<blockquote>
<p>Thus, I have not found the cause yet.</p>
</blockquote>
<p>But I've found a workaround for you, Bill.</p>
<p>In definition of ZZZZ::PROTO::RPCMessageDispatcher#rpc_connection_unbind,<br>
you should use<br>
@msg_portmap[MSGPORT_ROOT].call(true, :rpc_unbind)<br>
instead of<br>
rpc_dispatch(MSGPORT_ROOT, MSGPORT_ROOT, :rpc_unbind)<br>
.</p>
<a name="Regards"></a>
<h2 >Regards,<a href="#Regards" class="wiki-anchor">¶</a></h2>
<p>U.Nakamura <a href="mailto:usa@garbagecollect.jp" class="email">usa@garbagecollect.jp</a></p>
<p>=end</p> Ruby master - Bug #3523: win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/3523?journal_id=124532010-07-21T21:41:58Zspatulasnout (B Kelly)billk@cts.com
<ul></ul><p>=begin<br>
Hi,</p>
<p>U.Nakamura wrote:</p>
<blockquote>
<p>But I've found a workaround for you, Bill.</p>
<p>In definition of ZZZZ::PROTO::RPCMessageDispatcher#rpc_connection_unbind,<br>
you should use<br>
@msg_portmap[MSGPORT_ROOT].call(true, :rpc_unbind)<br>
instead of<br>
rpc_dispatch(MSGPORT_ROOT, MSGPORT_ROOT, :rpc_unbind)<br>
.</p>
</blockquote>
<p>Interesting.</p>
<p>Do we know why it is unsafe to use run_in_fiber specifically during the<br>
unbind callback?</p>
<p>Note that test_em_fiber4f.rb represents an extremely simplified version<br>
of the system, and that normally rpc_dispatch is also frequently called<br>
from another EventMachine callback: receive_data.</p>
<p>So I am wondering if we have a reason to believe that it is <em>only</em> the<br>
unbind callback that is unsafe? And if we should expect the<br>
receive_data callback to be safe for run_in_fiber, unlike unbind?</p>
<p>(Unfortunately, unlike c0000029, I'm not yet able to reproduce the<br>
current memory corruption crash when running tests that exercise the<br>
real system. So I don't know if this change in test_em_fiber4f.rb<br>
makes a difference in the real system or not, since I can't get the<br>
real system to crash either way, yet.)</p>
<p>Thanks,</p>
<p>Bill</p>
<p>=end</p> Ruby master - Bug #3523: win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/3523?journal_id=124732010-07-22T09:44:35Zusa (Usaku NAKAMURA)usa@garbagecollect.jp
<ul></ul><p>=begin<br>
Hello,</p>
<p>In message "<a href="https://blade.ruby-lang.org/ruby-core/31403">[ruby-core:31403]</a> Re: [Bug <a class="issue tracker-1 status-8 priority-4 priority-default closed" title="Bug: win32 exception c0000029 on exit using fibers (Third Party's Issue)" href="https://bugs.ruby-lang.org/issues/3523">#3523</a>][Assigned] win32 exception c0000029 on exit using fibers"<br>
on Jul.21,2010 21:41:45, <a href="mailto:billk@cts.com" class="email">billk@cts.com</a> wrote:</p>
<blockquote>
<p>Interesting.</p>
<p>Do we know why it is unsafe to use run_in_fiber specifically during the<br>
unbind callback?</p>
</blockquote>
<p>Because it's called from the C++ destructor.<br>
When swiching fibers in ruby code which is called from C++<br>
destructor, the heap of destructing C++ object seems to be<br>
corrupted.<br>
I've not understood yet why switching fibers corrupt the<br>
heap and how to avoid the corruption.</p>
<p>So, now I can say only that you should not switch fibers<br>
with the posibility to be called in C++ destructor.</p>
<a name="Regards"></a>
<h2 >Regards,<a href="#Regards" class="wiki-anchor">¶</a></h2>
<p>U.Nakamura <a href="mailto:usa@garbagecollect.jp" class="email">usa@garbagecollect.jp</a></p>
<p>=end</p> Ruby master - Bug #3523: win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/3523?journal_id=124752010-07-22T12:29:11Zspatulasnout (B Kelly)billk@cts.com
<ul></ul><p>=begin<br>
U.Nakamura wrote:</p>
<blockquote>
<p>So, now I can say only that you should not switch fibers<br>
with the posibility to be called in C++ destructor.</p>
</blockquote>
<p>Ah. Thank you for the clarification!</p>
<p>Regards,</p>
<p>Bill</p>
<p>=end</p> Ruby master - Bug #3523: win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/3523?journal_id=125902010-07-29T21:29:02Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>3</i></li></ul><p>=begin<br>
Hi,</p>
<p>I'm changing this to Low priority.<br>
I'm sorry because you did good work, though.</p>
<p>According to unak's (painful) investigation, this bug seems to be<br>
caused by resuming fiber from C++ destructor.</p>
<p>It is very horrible for me. I can't imagine what it will cause.<br>
It is good to ask the author of eventmachine to investigate this,<br>
though this may be actually Ruby core's bug. In principle, Ruby<br>
assumes that extension library be written in C.</p>
<p>In addition, I believe this is a rare case.</p>
<p>--<br>
Yusuke Endoh <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a><br>
=end</p> Ruby master - Bug #3523: win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/3523?journal_id=126002010-07-30T08:11:06Zspatulasnout (B Kelly)billk@cts.com
<ul></ul><p>=begin<br>
Hi,</p>
<p>Yusuke Endoh wrote:</p>
<blockquote>
<p>I'm changing this to Low priority.<br>
I'm sorry because you did good work, though.</p>
<p>According to unak's (painful) investigation, this bug seems to be<br>
caused by resuming fiber from C++ destructor.</p>
<p>It is very horrible for me. I can't imagine what it will cause.<br>
It is good to ask the author of eventmachine to investigate this,<br>
though this may be actually Ruby core's bug. In principle, Ruby<br>
assumes that extension library be written in C.</p>
<p>In addition, I believe this is a rare case.</p>
</blockquote>
<p>Thanks for the update. I've conveyed the information to the<br>
EventMachine list.</p>
<p>By the way, I am still using 1.9.2 with cont.d back-ported<br>
from trunk, with FIBER_USE_NATIVE enabled.</p>
<p>So far it has been flawless. I haven't been able to reproduce<br>
any of these errors when trunk's cont.c is used.</p>
<p>Regards,</p>
<p>Bill</p>
<p>=end</p> Ruby master - Bug #3523: win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/3523?journal_id=177082011-06-11T14:40:05Zko1 (Koichi Sasada)
<ul></ul><p>Can we close this issue?</p> Ruby master - Bug #3523: win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/3523?journal_id=320572012-10-31T16:27:51Zusa (Usaku NAKAMURA)usa@garbagecollect.jp
<ul><li><strong>Status</strong> changed from <i>Assigned</i> to <i>Third Party's Issue</i></li></ul><p>Although it is too late, I think that we don't handle this now,<br>
so change this ticket as TPI.</p>