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, ple
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
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 wrote:
> Hi,
>
> I'll repeat my question if you'll excuse me:
>
> Zoltan (or anyone else knowing how this works) cou
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 runti
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
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
>
On Thu, Sep 17, 2009 at 2:43 PM, Zoltan Varga wrote:
> Hi,
>
> The runtime tries to abort all threads and waits for them to terminate, so
> if a thread refuses
> to die for some reason, the runtime will hang. Its possible that the serial
> port code doesn't
> check for thread aborts/interruption
2009/9/17 Kornél Pál :
> Hi,
>
> Zoltan Varga wrote:
>>
>> The runtime tries to abort all threads and waits for them to terminate,
>> so if a thread refuses
>> to die for some reason, the runtime will hang. Its possible that the
>
> This hang has occurred or different reasons and was reported seve
Hi,
Zoltan Varga wrote:
> The runtime tries to abort all threads and waits for them to
> terminate, so if a thread refuses
> to die for some reason, the runtime will hang. Its possible that the
This hang has occurred or different reasons and was reported several times.
Is there a specific re
We are checking that. However, using serial is not the only scenario
that this behaviour occurs, it's just the easiest to replicate. We are
now looking through some "mono --trace" outputs that contain no
SerialPort interaction at all and [probably] the same lockup had taken
place.
Mostly unrelated
Hi,
The runtime tries to abort all threads and waits for them to terminate, so
if a thread refuses
to die for some reason, the runtime will hang. Its possible that the serial
port code doesn't
check for thread aborts/interruptions.
Zoltan
On Thu, Sep 17, 2009 at 2:33 PM, Leszek C
Oh! We found something with "mono --trace" that we missed before. It
seems that we are Thread.Abort() 'ing a thread thats inside
SerialPort.Read() (and through this and serial.c - in kernel mode) and
the abort gets ignored. However, on the managed side, everything
proceeds as though the thread was
That's the
> kill -3 PID prints:
> "0" tid=0x0xb7d206f0 this=0x0x2fed8 thread handle 0x404 state: waiting
> on 0x400 : Event owns ()
result, nothing more is printed...
On Thu, Sep 17, 2009 at 1:25 PM, Zoltan Varga wrote:
> Hi,
>
> My mistake. You should send a SIGQUIT signal.
>
>
Hi,
My mistake. You should send a SIGQUIT signal.
Zoltan
On Thu, Sep 17, 2009 at 12:58 PM, Leszek Ciesielski wrote:
> Hi,
>
> kill -SIGUSR1 PID prints
>
> User definied signal 1
>
> And Mono terminates. Does this suggest no managed threads were left
> (there are 10 or 11 while th
Hi,
kill -SIGUSR1 PID prints
User definied signal 1
And Mono terminates. Does this suggest no managed threads were left
(there are 10 or 11 while the application is running)? gdb native
stack trace follows:
0xe430 in __kernel_vsyscall ()
(gdb) thread apply all bt
Thread 4 (Thread 0xb7573b9
Hi,
You can attach to the hung process with gdb and type
'thread apply all bt' to get a native backtrace, and/or
send a SIGUSR1 signal to the process to print a manager backtrace.
Zoltan
On Thu, Sep 17, 2009 at 12:15 PM, Leszek Ciesielski wrote:
> Hi,
>
> we have tried to isola
Hi,
we have tried to isolate the problem for almost a month, the best we
managed to get is a hardware configuration for our application that
hangs on every exit - but this is with about 8MB of binaries, probably
over 100k SLOC. What I am hoping for now are some gdb guidelines to
pinpoint the probl
Hi,
Could you create some kind of test case to help us debug this issue ?
Zoltan
On Thu, Sep 17, 2009 at 11:28 AM, Leszek Ciesielski wrote:
> Hi,
>
> I am experiencing Mono hangup when my application should terminate.
> The application opens multiple serial ports, but the bug has
Hi,
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. Any
19 matches
Mail list logo
