[Mono-dev] Mono hangs on shutdown when /dev/ttySx ports were opened.

[Leszek Ciesielski]

Seems that the SerialPort was a red herring - the Mono "hang on exit"
occurs even when I use a "stub" SerialPort that never calls any native
code (i.e. mono and mcs from svn, no DllImports in SerialPortStream.cs
at all). However, I still have no idea what actually is causing the
lock. Any help, please?

On Tue, Sep 22, 2009 at 6:17 PM, Leszek Ciesielski <skolima at gmail.com> wrote:
> Hi,
>
> whenever code in mono/mono/io-layer/ performs blocking operations, it
> is done in a loop like this:
>
>      do {
>                ret = write (fd, buffer, numbytes);
>        } while (ret == -1 && errno == EINTR &&
>                 !_wapi_thread_cur_apc_pending());
>
> serial.c does not include _wapi_thread_cur_apc_pending() check and
> loops happily forever, ignoring all EINTRs. Is this the bug causing
> the hang? I tried adding this check in appropriate places in serial.c,
> however, this breaks mono at runtime with:
>
> mono: symbol lookup error: /opt/mono/lib/libMonoPosixHelper.so:
> undefined symbol: _wapi_thread_cur_apc_pending
>
> The function is defined in libmono.so, which libMonoPosixHelper.so
> does not link to... Am I on the right track with the
> _wapi_thread_cur_apc_pending(), or does the code living in
> mono/support/ just have to return to managed land in order to handle
> EINTR's properly (i.e. is _wapi_thread_cur_apc_pending() usage
> restricted to libmono residents only)?
>
> Regards,
>
> skolima
>
> On Tue, Sep 22, 2009 at 12:36 PM, Zoltan Varga <vargaz at gmail.com> wrote:
>> Hi,
>>
>>   Yes the runtime only aborts threads which execute native code when they
>> return to
>> managed code.
>>
>>                   Zoltan
>>
>> On Tue, Sep 22, 2009 at 11:35 AM, Leszek Ciesielski <skolima at gmail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> I'll repeat my question if you'll excuse me:
>>>
>>> Zoltan (or anyone else knowing how this works) could you please
>>> explain how the mono/mono/support/*.c code should execute native
>>> blocking calls so that the runtime can shutdown correctly? From
>>> reading into threads.c I am now guessing that the runtime does not
>>> signal the native threads in any way, it just waits for a managed
>>> thread switch to inject ThreadAbortException - is this a correct
>>> assumption? If yes, then the blocking native calls should return every
>>> few seconds (or probably even more often) and force the managed thread
>>> switch with Thread.Sleep() so as to give the runtime the opportunity
>>> to terminate them in an orderly manner. I think I can fix the serial.c
>>> code, I just have to understand better how it should behave to avoid
>>> locking.
>>>
>>> Regards,
>>>
>>> skolima
>>>
>>> On Mon, Sep 21, 2009 at 2:03 PM, Zoltan Varga <vargaz at gmail.com> wrote:
>>> > Hi,
>>> >
>>> >   This is very tricky problem. The runtime waits for all application
>>> > threads
>>> > to finish before exiting in order to have a predictable shutdown and to
>>> > be
>>> > compatible with ms.net. If we didn't
>>> > wait for them, and started to free up the runtime data structures, then
>>> > one
>>> > of the running threads could  access the freed data and crash/misbehave.
>>> > You
>>> > might want to try to
>>> > close the file descriptor the thread is waiting on, that might break the
>>> > wait.
>>> >
>>> >                               Zoltan
>>> >
>>> > On Mon, Sep 21, 2009 at 10:07 AM, Christian Hoff
>>> > <christian_hoff at gmx.net>
>>> > wrote:
>>> >>
>>> >> Leszek Ciesielski wrote:
>>> >> > I am experiencing Mono hangup when my application should terminate.
>>> >> > The application opens multiple serial ports, but the bug has also
>>> >> > manifested when network sockets were hanging on reads or writes - it
>>> >> > seems to be related to a pending I/O operation, asynchronous
>>> >> > networking helps somewhat. Anyway, the managed code exits, Mono CPU
>>> >> > usage jumps to 100%, /proc/PID/status shows 4 threads and the
>>> >> > application never exits.
>>> >> >
>>> >> Great to see that this issue is being actively worked on! I'm
>>> >> experiencing the same problem with my application which uses serial
>>> >> ports. The workaround I'm using so far is to set the read timeout to
>>> >> something about 500.
>>> >>
>>> >> As you have probably figured out already, the problem seems to be that
>>> >> Mono does not abort calls to native API. SerialPort.ReadByte pinvokes a
>>> >> blocking function in MonoPosixHelper.
>>> >>
>>> >> I'm not sure if native API calls should be aborted by the Mono runtime.
>>> >> Maybe the best solution here is to see how the func is implemented in
>>> >> MonoPosixHelper and see if we possibly avoid the blocking native call.
>>> >>
>>> >>
>>> >> Christian
>>> >> _______________________________________________
>>> >> Mono-devel-list mailing list
>>> >> Mono-devel-list at lists.ximian.com
>>> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>> >
>>> >
>>
>>
>