[Mono-bugs] [Bug 605864] New: Thread Aborts/Unknown Metafile Format Problems
bugzilla_noreply at novell.com
bugzilla_noreply at novell.com
Fri May 14 04:49:15 EDT 2010
Summary: Thread Aborts/Unknown Metafile Format Problems
Product: Mono: Runtime
OS/Version: Mac OS X 10.6
Priority: P5 - None
AssignedTo: mono-bugs at lists.ximian.com
ReportedBy: ron.ducros at livedrive.com
QAContact: mono-bugs at lists.ximian.com
Found By: ---
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
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.
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
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:] +
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
Any advice on helping to understand and resolve this would be greatly
Reproducible: Couldn't Reproduce
Steps to Reproduce:
See description - abort called and app terminates.
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:
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.
More information about the mono-bugs