Bug 435392 - Mono aborts causing iFolder to not function
Summary: Mono aborts causing iFolder to not function
Status: RESOLVED FIXED
Alias: None
Product: Mono: Runtime
Classification: Mono
Component: JIT (show other bugs)
Version: 1.2.2
Hardware: Other Other
: P5 - None : Critical
Target Milestone: ---
Assignee: Forgotten User vxPDddArjq
QA Contact: Mono Bugs
URL:
Whiteboard:
Keywords: DSLA_REQUIRED
Depends on:
Blocks:
 
Reported: 2008-10-14 20:08 UTC by Kalidas Balakrishnan
Modified: 2009-05-20 22:40 UTC (History)
3 users (show)

See Also:
Found By: Customer
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Apache error log wioth stack trace (107.17 KB, text/plain)
2008-11-12 20:23 UTC, Bob Bowles
Details
Apache error log wioth stack trace (107.17 KB, text/plain)
2008-11-12 20:23 UTC, Bob Bowles
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kalidas Balakrishnan 2008-10-14 20:08:04 UTC
Mono aborts with the following error, while iFolder is running behind apache using mod-mono

** ERROR **: file domain.c: line 177 (mono_jit_info_table_find): assertion failed: (ret == 0)
aborting...

** (process:24516): ERROR (recursed) **: file domain.c: line 177 (mono_jit_info_table_find): assertion failed: (ret == 0)
aborting...

** (process:24516): ERROR (recursed) **: file domain.c: line 177 (mono_jit_info_table_find): assertion failed: (ret == 0)
aborting...

** (process:24516): ERROR (recursed) **: file domain.c: line 177 (mono_jit_info_table_find): assertion failed: (ret == 0)
aborting...

** (process:24516): ERROR (recursed) **: file domain.c: line 177 (mono_jit_info_table_find): assertion failed: (ret == 0)
aborting...

** (process:24516): ERROR (recursed) **: file domain.c: line 177 (mono_jit_info_table_find): assertion failed: (ret == 0)
aborting...
Comment 1 Kalidas Balakrishnan 2008-10-14 20:09:34 UTC
Following are the version of mono and mod-mono installed in the customer server

mono-winforms-1.2.2-12.19.6
mod_mono-1.2.5-0.2
mono-core-1.2.2-12.19.6
mono-data-1.2.2-12.19.6
mono-web-1.2.2-12.19.6
dbus-1-mono-0.60-33.20.3
xsp-1.2.5-17.2

 The customer has installed OES1 (SLED10 SP1) with latest mono updates.
Comment 2 Miguel de Icaza 2008-10-16 16:34:05 UTC
Please provide stack traces of the above problems when the errors occur, see:

www.mono-project.com/Debugging for information on how to obtain those stack traces.

You might want to set a breakpoint on g_log to ease the process.
Comment 3 Kalidas Balakrishnan 2008-11-03 10:44:49 UTC
Adding Bob as the info provider as the setup is available.
Comment 4 Bob Bowles 2008-11-03 18:35:34 UTC
This is a customers production server and I am not going to have them recompile mono to troubleshoot an iFolder issue.

What else do you suggest?
Comment 5 Bob Bowles 2008-11-10 17:09:06 UTC
upgraded mono to version 1.2.6 and installed the debug package from
http://ftp.novell.com/pub/mono/archive/1.2.6/download/suse-101-i586/

will monitor and attach debug log if/when mono aborts.

Comment 6 Bob Bowles 2008-11-10 17:10:02 UTC
iFolder bug 443456 dependant on this bug.
Comment 7 Bob Bowles 2008-11-12 20:23:11 UTC
Created attachment 251716 [details]
Apache error log wioth stack trace
Comment 8 Bob Bowles 2008-11-12 20:23:31 UTC
Created attachment 251717 [details]
Apache error log wioth stack trace
Comment 9 Forgotten User eSgqzbHCW8 2008-11-17 16:26:37 UTC
Miguel, is the information provided by Bob sufficient? Do we need to update with any other information for debugging? Can you let us know the status of this bug? Customer is unable to use iFolder because of this issue. Can you please look into it?
Comment 10 Miguel de Icaza 2008-11-18 22:17:13 UTC
Zoltan, would you mind checking these logs?

It does look like the same startup race condition that we saw in the other bug though
Comment 11 Forgotten User vxPDddArjq 2008-11-18 22:32:13 UTC
Here is the same patch I attached to the other bug report:
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Index: mono/metadata/assembly.c
===================================================================
--- mono/metadata/assembly.c    (revision 112598)
+++ mono/metadata/assembly.c    (working copy)
@@ -1475,7 +1475,6 @@
        g_hash_table_insert (ass_loading, (gpointer)GetCurrentThreadId (), loading);
        mono_assemblies_unlock ();

-       g_assert (image->assembly == NULL);
        image->assembly = ass;

        mono_assembly_load_references (image, status);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

This just removes the assert which is hit, which is probably safe. Please try
it out.
Comment 12 Kalidas Balakrishnan 2008-11-21 06:09:14 UTC
Adding Craig to the bug. Craig re-built Mono with the above patch for SLES10 SP2.

 Craig, is it possible to build Mono for SLES10 SP1 (aka OES2) as well?

 Bob, once Craig rebuilds Mono with the above patch, then you can provide the patch to the customer to try.
Comment 13 craig gardner 2008-11-21 13:25:37 UTC
Already done with the previous patch.  The patch was built and delivered to both SLES10 SP1 and SLES10 SP2.

slesp1-mono-core-5645
slesp2-mono-core-5645

> rpm -qp --changelog 10-SP1/rpm/i586/mono-core.rpm |head -4
* Tue Sep 30 2008 - cgardner@suse.de
- Patch for bnc#429997 (back port fix for race condition)
- Patch for bnc#419989 (fix for crash on x86_64 amd guest in xen)
Comment 14 Bob Bowles 2008-11-24 19:00:16 UTC
Has this patch been delivered to the SLES 10 SP1 channel?

Where can I get this patch?
Comment 15 Kalidas Balakrishnan 2008-11-25 07:37:31 UTC
Craig?
Comment 16 craig gardner 2008-11-25 15:37:05 UTC
The patch was already identified, in comment #13.  Posted to nu.novell.com around 2 Oct 2008.

SLES10 SP1
<rpm:entry kind="atom" name="mono-core" epoch="0" ver="1.2.2" rel="12.19.6" flags="EQ"/>

SLES10 SP2
<rpm:entry kind="atom" name="mono-core" epoch="0" ver="1.2.2" rel="12.24" flags="EQ"/>
Comment 17 Rodrigo Kumpera 2009-05-20 22:40:14 UTC
Following the previous comment I believe this is fixed.