Bug 2028 - mono/monotouch - a failed conditional's next statement is incorrect.
Summary: mono/monotouch - a failed conditional's next statement is incorrect.
Alias: None
Product: Runtime
Classification: Mono
Component: General ()
Version: unspecified
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2011-11-14 12:41 UTC by James Scheibel
Modified: 2011-11-15 02:29 UTC (History)
2 users (show)

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

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 GitHub or Developer Community 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 James Scheibel 2011-11-14 12:41:19 UTC
something seems wrong with the internal/underpinnings logic of conditionals. 
essentially if I nest a few if statements or a few if statements and have a for loop in the center. when the conditional check fails, instead of going to the next line after the for loop or outside the if statement. it jumps into an else block in the parent if statement.

in short

if (x=y){
   if (z=q){
      for(int k=1;k<c;k++){
        //do something
      x=x+1; /// this never runs
   if (r=k){
      //we end up down here after the for loop runs!

the problem with just giving you code to reproduce this, is apparently it takes a special set of circumstances to make happen. but you can step through the code and watch it jump mysteriously down a bit. I've seen it happen with if statements only and with if statements and a for loop.

I've tried turning on and off optimizers (they currently turned off) and cleaning the project in between switching the settings hoping for a new behavior. The app is using open gl but is otherwise doing nothing odd. I've endeavored to make a standalone app that reproduces the bug exactly, but have thus far not be able to. i'm slowly adding in more and more of the orignal projects code. I would provide the original projects code itself but it happens in the middle of a physics engine and is a lot to carry around to see a bug. 

Have you seen this problem before? Is it on the radar? The first time I saw the bug with the nested if statements only I was able to fix the problem by adding an else statement with no code in the else. this is not an option for the loop issue.

I'll be providing the sample code as soon as I get my standalone utility app to reproduce it. (unless you dont need it)

incidently no error is thrown.
Comment 1 James Scheibel 2011-11-15 02:29:27 UTC
apparently upon closer inspection, while the debugger trace highlight moves to a weird location. it never actually executes any code. so, there doesn't appear to be a bug.