http://bugzilla.novell.com/show_bug.cgi?id=605864
http://bugzilla.novell.com/show_bug.cgi?id=605864#c0 Summary: Thread Aborts/Unknown Metafile Format Problems Classification: Mono Product: Mono: Runtime Version: 2.6.x Platform: x86 OS/Version: Mac OS X 10.6 Status: NEW Severity: Normal Priority: P5 - None Component: misc AssignedTo: [email protected] ReportedBy: [email protected] QAContact: [email protected] Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-us) AppleWebKit/531.22.7 (KHTML, like Gecko) Version/4.0.5 Safari/531.22.7 Bug report is below - have filed at request of Novell support. Some extra information I didn't include in initial post: Mac OS X 10.6.3 - this is only OS I've had reports of this happening on. --- I posted the question below to the Mono OS X mailing list/forum a couple of days ago. To date I haven't had any response. I'd like to know the best way to proceed - I'm not sure I am convinced this is a bug versus my lack of understanding on how to correctly handle threads/embedded versions of the framework. I'm unable to produce a test case for filing a bug report as this is not currently reproducible in house. We've only encountered the error on a very small number of customers machines. Any advice on how to resolve the issue/try and collect sufficient information for filing a bug report would be appreciated. ------ Hi all, I have recently released a couple of versions of our application on OS X which uses an embedded version of Mono. Initially this shipped with 2.6.1 embedded - the embedding is done by creating a package using macpack and then moving the resources directory to our Cocoa GUI app and fixing install paths/names with install_name_tool. This approach was recommended by Novell support. For our first release we occasionally noticed some strange output in console such as: WARNING **: Unknown metafile format: key 1095062083 This didn't seem to cause any other problems and was very intermittent. I haven't filed a bug on this yet (shame on me sorry!) as it happens in a very large project and I simply haven't been able to give it sufficient time to try and get it down to a simple reproducible test case. Recently we released a new version of our product that had 2.6.4_3 embedded (as this had bug fixes that we needed). However we seem to have made the above issue worse (assuming they are related). We now have some customers reporting intermittent crashes - these have the following stack trace: Thread 29 Crashed: 0 libSystem.B.dylib 0x95a054be __semwait_signal_nocancel + 10 1 libSystem.B.dylib 0x95a053a2 nanosleep$NOCANCEL$UNIX2003 + 166 2 libSystem.B.dylib 0x95a802f2 usleep$NOCANCEL$UNIX2003 + 61 3 libSystem.B.dylib 0x95aa19a8 abort + 105 4 libglib-2.0.0.dylib 0x0059c416 g_assertion_message + 253 5 libglib-2.0.0.dylib 0x0059ca43 g_test_run_suite_internal + 0 6 libmono.0.dylib 0x003b73b3 small_id_alloc + 949 7 libmono.0.dylib 0x003b87e7 mono_thread_attach + 341 8 com.livedrive.livedriveapp 0x0000c6bd -[MonoCommandHandler commandAttachThread] + 108 9 com.livedrive.livedriveapp 0x0000c870 -[MonoCommandHandler commandStart:] + 48 10 com.livedrive.livedriveapp 0x0000a9dc -[MonoManager sha256UpdateSize:length:hashID:] + 73 11 com.livedrive.livedriveapp 0x00028156 -[Sha256Hash generateHash:] + 870 12 com.apple.Foundation 0x911738dc -[NSThread main] + 45 13 com.apple.Foundation 0x9117388c __NSThread__main__ + 1499 14 libSystem.B.dylib 0x959c5a19 _pthread_start + 345 15 libSystem.B.dylib 0x959c589e thread_start + 34 In our hashing code we spawn a new NSThread which calls into the C# code we are running under mono and these code does a mono_thread_attach/mono_thread_detach for each thread we spawn (on the Mac side). I must admit to being a little puzzled at seeing the g_test_run_suite_internal but that does tie in with the first issue (where Novell support confirmed this message should only be coming from the Mono unit test code). Doing a google search for g_test_run_suite_internal only finds someone with a similar crash andhttp://bugzilla.novell.com/show_bug.cgi?id=445610 (which is quite old and shows a similar crash stacktrace - however this seems to be tied to using the profiler). I guess my question is - am I doing something wrong with either my embedding or thread handling? Any advice on helping to understand and resolve this would be greatly appreciated. Many thanks Ron Reproducible: Couldn't Reproduce Steps to Reproduce: 1. 2. 3. Actual Results: See description - abort called and app terminates. Expected Results: No abort should be called. It's interesting that this seems to happen on the libmono.0.dylib/libglib-2.0.0.dylib boundary - does make me wonder if I've done something stupid in the packaging (embedding the framework). You can download a copy of the latest version that shows this problem from: http://update.livedrive.com/updatelivedrive/Livedrive-1.0.26.31.dmg -- 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. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
