Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
* Clone https://github.com/rolfbjarne/TestApp
* Run on a device.
* Click one of the buttons to make it crash.
* Open the crash report in Xcode.
14 testapp 0x0018a70a mono_arm_throw_exception (exceptions-arm.c:161)
15 testapp 0x00132a94 ___lldb_unnamed_function5991$$testapp + 64
16 testapp 0x0015598c ___lldb_unnamed_function8419$$testapp + 68
17 testapp 0x0015ae94 ___lldb_unnamed_function8529$$testapp + 240
18 testapp 0x0015c0cc ___lldb_unnamed_function8554$$testapp + 92
19 testapp 0x00117534 ___lldb_unnamed_function5453$$testapp + 196
20 testapp 0x001a72a6 mono_jit_runtime_invoke (mini.c:6471)
I am hitting this, too. Please try to get it fixed asap!
I can no longer reproduce this with master.
Thanks for the update - when will that be available via alpha/beta channel?
I can still reproduce (but I had to enable LLVM first).
There seems to be two problems in fact (not sure if they're related or not):
1) The normal debug builds will get the function name right, but no file / line number information:
8 testapp 0x00037138 TestApp.AppDelegate:NativeCrash + 152
9 testapp 0x00037d84 TestApp.AppDelegate:<FinishedLaunching>m__2 + 120
10 testapp 0x001530cc MonoTouch_Dialog_StringElement_Selected_MonoTouch_Dialog_DialogViewController_MonoTouch_UIKit_UITableView_MonoTouch_Foundation_NSIndexPath + 68
11 testapp 0x001585d4 MonoTouch_Dialog_DialogViewController_Selected_MonoTouch_Foundation_NSIndexPath + 240
12 testapp 0x0015980c MonoTouch_Dialog_DialogViewController_Source_RowSelected_MonoTouch_UIKit_UITableView_MonoTouch_Foundation_NSIndexPath + 92
2) If I select the Release configuration and enable LLVM, I get the same issue as in the original description.
Tested with monotouch/fc0a1e46be.
The stacktrace in the ios console contains file/line numbers, but the crash report in the 'Device Logs' section does not.
Please make sure it is available within Instruments, too (I assume it is fetched from the .dSYM there?). Currently it is not possible to trace a memory leak (for example) down to the point in source causing it. What is a serious issue for everyone wanting to optimize their applications.
The file/line number support was broken when we switched to using clang as the assembler, we emit the generated machine code using .byte directives and clang doesn't consider those instructions, so it ignores the .loc directives emitted before those.
We can hack around that by emitting a nop at each pc which has a line number, but it will slow down code in release mode. Alternatively, llvm has an assembler called llvm-mc, and we can switch to that but it is risky, and it might not support arm64 at all.
I tried using clang's -integrated-as (which is supposedly using llvm-mc), and it didn't work either (I also tried -no-integrated-as, but nothing changed).
clang might be using an older version of llvm which had this problem.
Have you been able to make llvm-mc work?
I get an error:
./llvm-mc: error: invalid target 'armv7'.
And from the documentation it looks like it's not supported for arm: http://llvm.org/docs/CodeGenerator.html#target-feature-matrix
I used llvm-mc -arch=arm -filetype=obj. That seemed to work, but I'm not sure how reliable it is.
So I got llvm-mc to work, but nothing changed. I tried the llvm-mc we build as a part of our monotouch build, and also the latest version from their git. I also tried the latest clang version from their git, no difference, still no file names or line numbers.
BTW llvm-mc does not like the assembly files we create when LLVM is enabled, it reports a lot of errors.
The alternative is to add a hack which inserts a nop before each line number positions, that relatively easy to implement. Did we ever support file/line numbers in release mode ?
Yes, we did support file/line numbers in release mode (quite essential for crash reporting in released apps in fact).
Yet it would be an improvement if we could at least get debug builds to work properly.
This is somewhat better now with 98dbdd9cc505b7ccf150b641221139b00ec13c69. I get file/line numbers in debug mode.
Any news on this? It is currently almos impossible to debug an app regarding memory issues without getting to the source trough Instruments. Again, that's serious!
Zoltan, I can confirm it's better now, I get file/line numbers for some frames in both debug and release mode.
Sample crash (from the original test case): https://gist.github.com/rolfbjarne/dc52ea9e797a0c7eee00
Note how frame 9 is symbolicated correctly, while frames 10-12 are still lacking file/line number information.
@asp_net, the improvement mentioned in comment 15 will be included in 7.0.6 and 7.1 (soon to be released).
Made some progress in mono 3312a1af0c5bae33ec76b3ce45fb892d7c68447c, now the dSYM file contains debug info for all assemblies, not just the main one. Some frames still have no line number info because they make indirect calls, and the AOT compiler emits those using .byte directives, not assembly, i.e. comment #7.
Fixed the majority of this in mono f18648d642ca963c8dc02c5b41bb70276b65c207/mt fa6a7b38f86fb1806678917aa37005b0817efbf5. Debug builds now work ok with the testcase, release builds still have some lldb_unnamed symbols, but those look like wrappers, c# frames have normal names and line number info.
*** Bug 15812 has been marked as a duplicate of this bug. ***
Fixes from comment #19 and comment 20 backported to the 7.1 and 7.0.6 branches (the fix from comment #15 is already in both).
Could you take a look at the crash reports before and after applying the fix mentioned in Comment #22. I couldn't verify the bug since it looked similar.
TestApp CrashReport with MT 7.0.6 2ed9bc96337da73a7e5d00ed6c77f63f2489bb24:
TestApp CrashReport with beta 7.0.6 :
Version: 22.214.171.124 (Enterprise Edition)
Interestingly only Xcode 5.1 DP4 seem to symbolicate correctly, Xcode 5.0 does not.
Gouri, can you try again with Xcode 5.1? Note that you don't have to rebuild nor change anything else in the XI project, you only get the crash report using Xcode 5.1.
CrashReport from Xcode51-DP4
Version 4.3.1 (build 5)
Installation UUID: 5ed3a124-4b77-4c6f-beb9-c830fd815e2a
Mono 3.2.6 ((no/9b58377)
GTK+ 2.24.23 theme: Raleigh
Package version: 302060000
Apple Developer Tools
Xcode 5.1 (5051.4)
Version: 126.96.36.199 (Enterprise Edition)
Build date: 2014-21-01 16:35:21-0500
Yeah, that's a lot better.
This sounds like Apple fixed a bug in Xcode 5.1, so I suppose we'll just have to document that Xcode 5.0 won't be able to symbolicate properly.
Rolf: I have xcode 5.0, and symbolifications works ok for me.
Zoltan, did you test using mt master or the 7.0.6 branch?
Rolf: I tested using master. It looks like the 7.0.6 branch (2ed9bc96337da73a7e5d00ed6c77f63f2489bb24) contains both the required changes, so I don't know what the problem is. Also, what config doesn't work (debug/release/release-llvm) ?
Xcode 5.0/master/Debug: OK.
Xcode 5.0/master/Release: OK (a couple of wrapper_* methods shows up as lldb_unnamed_function).
Xcode 5.0/master/Release+llvm: many lldb_unnamed_functions.
Xcode 5.1/master/Debug: OK.
Xcode 5.1/master/Release: OK
Xcode 5.1/master/Release+llvm: OKish (functions symbolicated as C names instead of C# names, no filename/line numbers)
Xcode 5.0/7.0.6/Debug: OK
Xcode 5.0/7.0.6/Release: OK (a couple of wrapper_* methods shows up as lldb_unnamed_function).
Xcode 5.0/7.0.6/Release+llvm: many lldb_unnamed_functions.
Xcode 5.1/7.0.6/Debug: OK
Xcode 5.1/7.0.6/Release: OK
Xcode 5.1/7.0.6/Release+llvm: OKish (functions symbolicated as C names instead of C# names, no filename/line numbers)
To sum it up:
* Debug works in all cases.
* Release has a couple of minor lldb_unnamed_function w/Xcode 5.0 (but not 5.1).
* Release+llvm is quite unusable with Xcode 5.0, while it works OKish with Xcode 5.1
* I couldn't find any difference between 7.0.6 and master.
So any remaining issues should not hold up 7.0.6, since they haven't been fixed in master either.
Links to crash reports:
File/line info for LLVM functions was never supported, we didn't emit debug information for LLVM code.
Are there any plans to emit debug information for LLVM code in the future?
Yes, it will be supported in our next major release.