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

[Leszek Ciesielski]

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
>> >
>> >
>
>