Bug 1949 - Debugger shows incorrect values on iOS device
Summary: Debugger shows incorrect values on iOS device
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Debugger ()
Version: unspecified
Hardware: Macintosh Mac OS
: High normal
Target Milestone: ---
Assignee: Rolf Bjarne Kvinge [MSFT]
: 3809 7706 ()
Depends on:
Reported: 2011-11-08 16:14 UTC by Eric Maupin
Modified: 2014-01-13 16:46 UTC (History)
8 users (show)

Is this bug a regression?: ---
Last known good build:

Test case project (9.43 KB, application/zip)
2011-11-08 16:14 UTC, Eric Maupin
gdb session (6.17 KB, text/plain)
2012-03-30 20:29 UTC, Rolf Bjarne Kvinge [MSFT]
extended gdb session (11.06 KB, text/plain)
2012-03-30 20:37 UTC, Rolf Bjarne Kvinge [MSFT]

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:

Description Eric Maupin 2011-11-08 16:14:43 UTC
Created attachment 850 [details]
Test case project

MD 2.8.2, MT 5.0.2, running on iPhone 4 (5.0 9A334)

1. Open attached test project
2. Switch to Debug|iPhone configuration
3. Place a breakpoint on line 61
4. Start debugging and launch app
5. Press the button on the app
(you should now be sitting at the breakpoint)
6. Hover over both instances of "this.position.Accuracy" and notice the tooltips show different values
7. Enter "this.position.Accuracy" into the immediate window and notice you get a third different value.

Video demonstration, which also shows setting it reveals a random value each time: http://screencast.com/t/ZKJNHOYfl2
Comment 1 Jeffrey Stedfast 2011-11-28 13:47:02 UTC
Hmm, I'm not able to reproduce this on an iPad with iOS 5.0.1 (9A405)
Comment 2 Zoltan Varga 2011-11-28 15:07:22 UTC
Can't repro this on an ipad 2 either. Can somebody test with an iphone ?
Comment 3 Mikayla Hutchinson [MSFT] 2012-03-10 14:48:00 UTC
*** Bug 3809 has been marked as a duplicate of this bug. ***
Comment 4 Zoltan Varga 2012-03-10 22:25:16 UTC
Is there somebody with an iphone 4 who can reproduce this ?
Comment 5 Jeffrey Stedfast 2012-03-14 14:21:54 UTC
Alan? Rolf? can one of you guys reproduce this?
Comment 6 Rolf Bjarne Kvinge [MSFT] 2012-03-14 17:35:54 UTC
I can reproduce on an iPhone 4. Zoltan, what do you need to know?
Comment 7 Rolf Bjarne Kvinge [MSFT] 2012-03-14 17:36:51 UTC
Comment 8 Rolf Bjarne Kvinge [MSFT] 2012-03-27 19:44:12 UTC
I'll track this down since I can reproduce it.
Comment 9 Zoltan Varga 2012-03-29 04:09:35 UTC
rolf: the first step would be looking into debugger-agent.c, in do_invoke_method (), at this line:

		res = mono_runtime_invoke (m, this, args, &exc);

This should return a boxed double with the correct value, i.e. *(double*)mono_object_unbox (res) should
be correct. If not, then the problem might be in the
mono_runtime_invoke () infrastructure.  That one is pretty complex, it goes through a function
called mono_arch_finish_dyn_call () in mini-arm.c, there is a 	case MONO_TYPE_R8: {
code block there, after this line:
		*(double*)ret = *(double*)&regs;
*(double*)ret should contain the correct value.
Comment 10 Rolf Bjarne Kvinge [MSFT] 2012-03-29 20:41:50 UTC
*(double*)ret does not contain the correct value.
Comment 11 Zoltan Varga 2012-03-29 23:59:36 UTC
The way it is supposed to work is that the invoked method returns its result in two int registers (r0 and r1), and the value of those registers is in 'res' and 'res2'. Try setting a breakpoint at the end of the
method which is invoked, which should have a slightly encoded name like Foo_Bar_int. Towards the end of it, there should be an instruction like:
vmov	r0, r1, d2
Here, d2 is a floating point register which should contain the correct value, and after this instruction, its binary encoding will be stored into r0 and r1. The values of r0 and r1 should be equal to the values of 'res' and 'res2' in mono_arch_finish_dyn_call ().
Comment 12 Rolf Bjarne Kvinge [MSFT] 2012-03-30 20:29:23 UTC
Created attachment 1605 [details]
gdb session

I tried to step through the method until the vmov instruction, but the instruction is never reached (when sdb invokes the method). It looks like we end up accessing an invalid memory, but for some reason mono_runtime_invoke does not return an exception though.

Attached is a gdb session where I've put a breakpoint on the invoked method. The first time the bp is hit is because of the normal program flow, and I can step through the entire method.

The second time the bp is hit is because I'm evaluating the method from MD. This time we access invalid memory when executing 0x0004bd3c.
Comment 13 Rolf Bjarne Kvinge [MSFT] 2012-03-30 20:37:44 UTC
Created attachment 1606 [details]
extended gdb session

Another gdb session, this time displaying the relevant registers at each instruction.
Comment 14 Zoltan Varga 2012-03-31 02:04:51 UTC
The fault is caused by the debugger sequence point code, which is implemented by reading read-protected memory, so its perfectly normal. Try placing a breakpoint on the vmov instruction directly, i.e.
break *0x0004bd88.
Comment 15 Rolf Bjarne Kvinge [MSFT] 2012-04-04 18:53:06 UTC
It is a SIGSEGV.

I added the breakpoint as you said, and it's not hit.

I added a printf in mono's mono_sigsegv_signal_handler, and that printf is hit when the sdb executes the method.
Comment 16 Zoltan Varga 2012-04-05 02:41:46 UTC
It is a SIGSEGV, but the SIGSEGV is used to implement debugger single stepping, which is kept enabled while executing debugger invokes. So it is normal, if you do a continue in the debugger, the app should continue to run normally.
Comment 17 Rolf Bjarne Kvinge [MSFT] 2012-04-05 04:24:04 UTC
The app does not continue normally.
Comment 18 Zoltan Varga 2012-04-05 11:36:38 UTC
Maybe gdb/xcode doesn't like these SIGSEGVs and can't process them normally.
Comment 19 Rolf Bjarne Kvinge [MSFT] 2012-04-05 13:18:55 UTC
In either case the only solution is to sprinkle printfs around. Any hints/ideas where I should start?
Comment 20 Zoltan Varga 2012-04-05 13:39:33 UTC
You can try commenting out this line in debugger-agent.c:
                tls->pending_invoke->flags = flags;
this will hopefully turn off the SIGSEGV machinery during invokes. It might even "fix" the problem.
Comment 21 Rolf Bjarne Kvinge [MSFT] 2012-04-09 19:20:44 UTC
Commenting out that line breaks everything (nothing is evaluated at all, continue doesn't work, etc).

However what did work, was to comment out the calls to mono_arch_start|stop_single_stepping. It also "fixed" the problem, the evaluated properties are now correct.
Comment 22 Zoltan Varga 2012-04-09 19:27:33 UTC
It looks like our signal handlers don't save/restore fp registers, so this is proba=bly the source of this problem. The C native code executed by the signal handlers might clobber these registers on the iphone4, and not on an ipad due to C compiler/libc differences. This might explain why this only happens for some platforms. I'll look into fixing this. Thanks for the help.
Comment 23 Zoltan Varga 2012-04-10 15:50:40 UTC
I can repro this now even on an ipad by putting dummy float code into process_single_step ().
Comment 24 Zoltan Varga 2012-04-11 07:20:36 UTC
rolf: Should be fixed in mobile-master, could you try it out ?
Comment 25 Rolf Bjarne Kvinge [MSFT] 2012-04-11 20:00:57 UTC
Yep, it's fixed now.
Comment 26 Jonathan Pryor 2014-01-13 16:46:19 UTC
*** Bug 7706 has been marked as a duplicate of this bug. ***