Bug 36052 - Using stackalloc zeros out the size variable when passed to another function
Summary: Using stackalloc zeros out the size variable when passed to another function
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: JIT (show other bugs)
Version: 4.0.0
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2015-11-19 11:11 UTC by Eric Erhardt
Modified: 2015-11-19 14:19 UTC (History)
3 users (show)

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


Attachments
The project.json file that is needed to run the program with dnx. (665 bytes, application/octet-stream)
2015-11-19 11:11 UTC, Eric Erhardt
Details
The C# code file that demonstrates the bug. (725 bytes, text/plain)
2015-11-19 11:12 UTC, Eric Erhardt
Details


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:
Status:
RESOLVED FIXED

Description Eric Erhardt 2015-11-19 11:11:41 UTC
Created attachment 13890 [details]
The project.json file that is needed to run the program with dnx.

When using "stackalloc char[bufferSize]" and then passing bufferSize into another function, the Mono runtime will clear/zero out the bufferSize variable.  This can be demonstrated with the following code:

using System;

namespace DNXTest
{
    public class Program
    {    
        public unsafe static void Main(string[] args)
        {
            Program p = new Program();
            
            string typeName = typeof(Program).Name;
            int bufferSize = 45;
            
            fixed (char* value = typeName)
            {  
                char* buffer = stackalloc char[bufferSize];
                p.EncodeIntoBuffer(value, typeName.Length, buffer, bufferSize);
            }
        }
        
        private unsafe void EncodeIntoBuffer(char* value, int valueLength, char* buffer, int bufferLength)
        {
            Console.WriteLine("bufferLength is " + bufferLength);
        }       
    }
}

I expect to get output that says "bufferLength is 45" which is what I get when running on the coreclr, but instead on the Mono runtime I get "bufferLength is 0".

I am using Mono version 4.0.4.0 on a MacBook Pro OS X El Capitan.

I am using 'dnx run' to run the program, not mcs/mono.  (Although, the code doesn't work on mcs/mono either - I am getting an unexpected NullReferenceException when running it through mcs/mono.)

To set up a repro:

1. Install Mono on the Mac.
2. Install the ASP.NET 5 RC from http://get.asp.net
3. In a terminal, make sure you are using the mono runtime by running: dnvm use 1.0.0-rc1-final -r mono
4. Copy the attached project.json file into a folder.  Also add the above code into the same folder, giving the file the name Program.cs.
5. In a terminal, navigate to the folder with Program.cs and project.json.
6. dnu restore
7. dnx run

Note: This bug was found through investigating the following higher-level issues:
https://github.com/aspnet/Mvc/issues/3465
https://github.com/dotnet/corefx/issues/4455
Comment 1 Eric Erhardt 2015-11-19 11:12:42 UTC
Created attachment 13891 [details]
The C# code file that demonstrates the bug.
Comment 2 Zoltan Varga 2015-11-19 14:19:38 UTC
Fixed in mono master 27432be3ec4c65ba618b18389561b57e2b2716cb. Thanks for the report.