[Mono-bugs] [Bug 494448] Application using thread pool has random intermittent failures

[bugzilla_noreply at novell.com]

http://bugzilla.novell.com/show_bug.cgi?id=494448

User apenn at hchb.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=494448#c5


Arthur Penn <apenn at hchb.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |NEW
      Info Provider|apenn at hchb.com              |




--- Comment #5 from Arthur Penn <apenn at hchb.com>  2009-04-21 11:20:07 MDT ---
Sorry about the delay. We've been looking into this and are a bit puzzled. Here
are the steps we have taken to try to duplicate the problem:

1. We built a test VM with Ubuntu at the same revision (8.04.1) as the physical
server with the problem and built Mono 2.4 with the same switches as production
(--with-libgdiplus=no). We ran our application and it did not ever fail.

2. We did a physical-to-virtual conversion of the physical server with the
problem and tested the application. It had the same problem behavior as
production.

3. I can't easily provide the original Mono application for various reasons
(primarily the environmental dependencies required to make it run), but we
built a test application that does substantially the same thing--the threads
look at file times and compare those file times to see if they are current
enough (comparing with DateTime.Now). I am posting the sample application (to
run it, just pass it a path with some files in it to check via the command line
argument 0). However, it does not fail in any environment--the problematic
P2V'd production instance or any other Ubuntu server where we have built Mono
2.2 or 2.4.

4. We traced the original application in the problematic production environment
with strace. We are seeing problems in the trace where it is puking after
gettimeofday calls (presumably when the thread is doing DateTime.Now
comparisons with the file time):

gettimeofday({1240320578, 485162}, NULL) = 0
close(4)                                = 0
gettimeofday({1240320578, 485322}, NULL) = 0
futex(0x871ba0, 0x81 /* FUTEX_??? */, 1) = 1
gettimeofday({1240320578, 485729}, NULL) = 0
gettimeofday({1240320578, 485806}, NULL) = 0
gettimeofday(**
** ERROR:(error.c:70):SetLastError: assertion failed: (ret == 0)
{1240320578, 485959}, NULL) = 0
rt_sigaction(SIGFPE, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGILL, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGBUS, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGRT_3, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGABRT, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGSEGV, {SIG_DFL}, NULL, 8) = 0
Stacktrace:

gettimeofday({1240320578, 486376}, NULL) = 0
  at Amib.Threading.SmartThreadPool.ProcessQueuedItems () <0xffffffff>
  at Amib.Threading.SmartThreadPool.ProcessQueuedItems () <0x00292>
  at (wrapper runtime-invoke) object.runtime_invoke_void__this__
(object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:

        /usr/bin/cli [0x481403]
        /lib/libpthread.so.0 [0x7fe0067667d0]
        /lib/libc.so.6(gsignal+0x35) [0x7fe0061a7095]
        /lib/libc.so.6(abort+0x110) [0x7fe0061a8af0]
        /usr/lib/libglib-2.0.so.0(g_assertion_message+0x117) [0x7fe006ddad97]
        /usr/lib/libglib-2.0.so.0 [0x7fe006ddb232]
        /usr/bin/cli [0x55072a]
        /usr/bin/cli [0x54575b]
        /usr/bin/cli [0x4f9069]
        /usr/bin/cli(mono_monitor_enter+0x10) [0x4f9420]
        [0x40f7c6a0]
gettimeofday({1240320578, 487491}, NULL) = 0

I am attaching the full trace file from strace. The error occurs at line 2809.

5. We compared the libraries (via ldd) against which we built Mono on the
working and non-working environments and they turned out to be the same.

Sorry I can't reproduce this on another machine--it's not for lack of trying.
Have you any other suggestions? Everything else on the production server and
its P2V'ed copy are working normally, including other Mono applications that
don't spin up threads.

-- 
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.