Skip to content

[browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0) #91528

Closed
#91589
Closed
[browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0)#91528
#91589
Assignees
pavelsavara
Labels
arch-wasmWebAssembly architecturearea-System.Runtime.InteropServices.JavaScriptos-browserBrowser variant of arch-wasm
Milestone
8.0.0

Description

@Tarun047
Tarun047
opened on Sep 4, 2023

Description

Hi,
I am facing a weird crash when using .NET 8 Latest Preview for targeting WASM Browser (AOT build).
The bug is observed in the following conditions.
The bug came out while benchmarking the performance of JS and .NET AOT Wasm.
When running a React Application, that uses web workers.
The idea is to let user select a file and to compress it using .NET WASM code.
Because this is a heavy task, a web worker is used to delegate the task to .NET WASM compression layer.
The Web App works fine with small files < 5MB.
But If we chose to go with larger files, the compression still succeeds (ofc until we hit OOM) but the .NET runtime exits abruptly with the following weird stack trace if we use files >10MB

Reproduction Steps

A repository to reproduce the issue is can he found here dotnet-wasm-react.

Inorder to reproduce this issue,

  1. Have the .NET 8.0.100-preview.7.23376.3 SDK and also install the wasm-tools, wasm-experimental workloads.

  2. Checkout the repository and perform the following actions:
    Publish the compress.csproj by running
    dotnet publish -c Release
    Copy the outputs of /bin/Release/net8.0/browser-wasm/AppBundle/ to compressy-frontend/public/vendor

  3. From the compressy-frontend folder,
    Install npm dependencies by running npm install and start the webpack dev server by running npm run dev

  4. Use a browser and navigate to http://localhost:8080 and keep the browser console window in browser dev tools open select the choose file button next to WASM .NET Compress and select any large file (>10MB preferably) in file chooser.

  5. check the console output for failure stack trace.

Expected behavior

The .NET WASM AOT runtime does not abruptly exit.

Actual behavior

The .NET WASM AOT Run time exits with following weird stack trace which I suspect is due to a possible stack corruption.

[Error] MONO_WASM: {"name":"ExitStatus","message":"Program terminated with exit(undefined)","stack":
"H@http://localhost:8080/vendor/_framework/dotnet.js:3:9846
@http://localhost:8080/vendor/_framework/dotnet.runtime.js:3:203721
_proc_exit@http://localhost:8080/vendor/_framework/dotnet.native.js:8:73946
exitJS@http://localhost:8080/vendor/_framework/dotnet.native.js:8:74058
maybeExit@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89407
Ko@http://localhost:8080/vendor/_framework/dotnet.runtime.js:3:56101
callUserCallback@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89507
@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89634","silent":true}
l (dotnet.js:3:673)
(anonymous function) (dotnet.js:3:10723)
H (dotnet.js:3:10910)
(anonymous function) (dotnet.runtime.js:3:203722)
_proc_exit (dotnet.native.js:8:73947)
exitJS (dotnet.native.js:8:74059)
maybeExit (dotnet.native.js:8:89408)
Ko (dotnet.runtime.js:3:56102)
callUserCallback (dotnet.native.js:8:89508)
(anonymous function) (dotnet.native.js:8:89635)

Regression?

The issue doesn't happen in .NET 7 WASM AOT builds

Known Workarounds

I haven't found a way to make this work

Configuration

Version: .NET 8.0.100-preview.7.23376.3
OS: Reproducible on Mac OS X, Windows.
Architecture: ARM64, X64
Browsers: Safari, Firefox, Chrome

Other information

No response

Metadata

Metadata

Assignees

Labels

arch-wasmWebAssembly architecturearea-System.Runtime.InteropServices.JavaScriptos-browserBrowser variant of arch-wasm

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    , 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
     blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
[browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0) · Issue #91528 · dotnet/runtime · GitHub
    Skip to content
    [browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0) #91528
    Closed
    #91589
    Closed
    [browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0)#91528
    #91589
    Assignees
    pavelsavara
    Labels
    arch-wasmWebAssembly architecturearea-System.Runtime.InteropServices.JavaScriptos-browserBrowser variant of arch-wasm
    Milestone
    8.0.0
    Description
    @Tarun047
    Tarun047
    opened on Sep 4, 2023
    Description
    Hi,
    
I am facing a weird crash when using .NET 8 Latest Preview for targeting WASM Browser (AOT build).
    
The bug is observed in the following conditions.
    
The bug came out while benchmarking the performance of JS and .NET AOT Wasm.
    
When running a React Application, that uses web workers.
    
The idea is to let user select a file and to compress it using .NET WASM code.
    
Because this is a heavy task, a web worker is used to delegate the task to .NET WASM compression layer.
    
The Web App works fine with small files < 5MB.
    
But If we chose to go with larger files, the compression still succeeds (ofc until we hit OOM) but the .NET runtime exits abruptly with the following weird stack trace if we use files >10MB
    Reproduction Steps
    A repository to reproduce the issue is can he found here dotnet-wasm-react.
    Inorder to reproduce this issue,
    1. Have the .NET 8.0.100-preview.7.23376.3 SDK and also install the wasm-tools, wasm-experimental workloads.
    2. Checkout the repository and perform the following actions:
      
Publish the compress.csproj by running
      dotnet publish -c Release
      
Copy the outputs of /bin/Release/net8.0/browser-wasm/AppBundle/ to compressy-frontend/public/vendor
    3. From the compressy-frontend folder,
      
Install npm dependencies by running npm install and start the webpack dev server by running npm run dev
    4. Use a browser and navigate to http://localhost:8080 and keep the browser console window in browser dev tools open select the choose file button next to WASM .NET Compress and select any large file (>10MB preferably) in file chooser.
    5. check the console output for failure stack trace.
    Expected behavior
    The .NET WASM AOT runtime does not abruptly exit.
    Actual behavior
    The .NET WASM AOT Run time exits with following weird stack trace which I suspect is due to a possible stack corruption.
    [Error] MONO_WASM: {"name":"ExitStatus","message":"Program terminated with exit(undefined)","stack":
"H@http://localhost:8080/vendor/_framework/dotnet.js:3:9846
@http://localhost:8080/vendor/_framework/dotnet.runtime.js:3:203721
_proc_exit@http://localhost:8080/vendor/_framework/dotnet.native.js:8:73946
exitJS@http://localhost:8080/vendor/_framework/dotnet.native.js:8:74058
maybeExit@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89407
Ko@http://localhost:8080/vendor/_framework/dotnet.runtime.js:3:56101
callUserCallback@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89507
@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89634","silent":true}
l (dotnet.js:3:673)
(anonymous function) (dotnet.js:3:10723)
H (dotnet.js:3:10910)
(anonymous function) (dotnet.runtime.js:3:203722)
_proc_exit (dotnet.native.js:8:73947)
exitJS (dotnet.native.js:8:74059)
maybeExit (dotnet.native.js:8:89408)
Ko (dotnet.runtime.js:3:56102)
callUserCallback (dotnet.native.js:8:89508)
(anonymous function) (dotnet.native.js:8:89635)

    Regression?
    The issue doesn't happen in .NET 7 WASM AOT builds
    Known Workarounds
    I haven't found a way to make this work
    Configuration
    Version: .NET 8.0.100-preview.7.23376.3
    
OS: Reproducible on Mac OS X, Windows.
    
Architecture: ARM64, X64
    
Browsers: Safari, Firefox, Chrome
    Other information
    No response
    Metadata
    Metadata
    Assignees
    Labels
    arch-wasmWebAssembly architecturearea-System.Runtime.InteropServices.JavaScriptos-browserBrowser variant of arch-wasm
    Type
    No type
    Projects
    No projects
      Milestone
      Relationships
      None yet
      Development
      No branches or pull requests
      Issue actions
      
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
[browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0) · Issue #91528 · dotnet/runtime · GitHub
      Skip to content
      [browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0) #91528
      Closed
      #91589
      Closed
      [browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0)#91528
      #91589
      Assignees
      pavelsavara
      Labels
      arch-wasmWebAssembly architecturearea-System.Runtime.InteropServices.JavaScriptos-browserBrowser variant of arch-wasm
      Milestone
      8.0.0
      Description
      @Tarun047
      Tarun047
      opened on Sep 4, 2023
      Description
      Hi,
      
I am facing a weird crash when using .NET 8 Latest Preview for targeting WASM Browser (AOT build).
      
The bug is observed in the following conditions.
      
The bug came out while benchmarking the performance of JS and .NET AOT Wasm.
      
When running a React Application, that uses web workers.
      
The idea is to let user select a file and to compress it using .NET WASM code.
      
Because this is a heavy task, a web worker is used to delegate the task to .NET WASM compression layer.
      
The Web App works fine with small files < 5MB.
      
But If we chose to go with larger files, the compression still succeeds (ofc until we hit OOM) but the .NET runtime exits abruptly with the following weird stack trace if we use files >10MB
      Reproduction Steps
      A repository to reproduce the issue is can he found here dotnet-wasm-react.
      Inorder to reproduce this issue,
      1. Have the .NET 8.0.100-preview.7.23376.3 SDK and also install the wasm-tools, wasm-experimental workloads.
      2. Checkout the repository and perform the following actions:
        
Publish the compress.csproj by running
        dotnet publish -c Release
        
Copy the outputs of /bin/Release/net8.0/browser-wasm/AppBundle/ to compressy-frontend/public/vendor
      3. From the compressy-frontend folder,
        
Install npm dependencies by running npm install and start the webpack dev server by running npm run dev
      4. Use a browser and navigate to http://localhost:8080 and keep the browser console window in browser dev tools open select the choose file button next to WASM .NET Compress and select any large file (>10MB preferably) in file chooser.
      5. check the console output for failure stack trace.
      Expected behavior
      The .NET WASM AOT runtime does not abruptly exit.
      Actual behavior
      The .NET WASM AOT Run time exits with following weird stack trace which I suspect is due to a possible stack corruption.
      [Error] MONO_WASM: {"name":"ExitStatus","message":"Program terminated with exit(undefined)","stack":
"H@http://localhost:8080/vendor/_framework/dotnet.js:3:9846
@http://localhost:8080/vendor/_framework/dotnet.runtime.js:3:203721
_proc_exit@http://localhost:8080/vendor/_framework/dotnet.native.js:8:73946
exitJS@http://localhost:8080/vendor/_framework/dotnet.native.js:8:74058
maybeExit@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89407
Ko@http://localhost:8080/vendor/_framework/dotnet.runtime.js:3:56101
callUserCallback@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89507
@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89634","silent":true}
l (dotnet.js:3:673)
(anonymous function) (dotnet.js:3:10723)
H (dotnet.js:3:10910)
(anonymous function) (dotnet.runtime.js:3:203722)
_proc_exit (dotnet.native.js:8:73947)
exitJS (dotnet.native.js:8:74059)
maybeExit (dotnet.native.js:8:89408)
Ko (dotnet.runtime.js:3:56102)
callUserCallback (dotnet.native.js:8:89508)
(anonymous function) (dotnet.native.js:8:89635)

      Regression?
      The issue doesn't happen in .NET 7 WASM AOT builds
      Known Workarounds
      I haven't found a way to make this work
      Configuration
      Version: .NET 8.0.100-preview.7.23376.3
      
OS: Reproducible on Mac OS X, Windows.
      
Architecture: ARM64, X64
      
Browsers: Safari, Firefox, Chrome
      Other information
      No response
      Metadata
      Metadata
      Assignees
      Labels
      arch-wasmWebAssembly architecturearea-System.Runtime.InteropServices.JavaScriptos-browserBrowser variant of arch-wasm
      Type
      No type
      Projects
      No projects
        Milestone
        Relationships
        None yet
        Development
        No branches or pull requests
        Issue actions
        
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
[browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0) · Issue #91528 · dotnet/runtime · GitHub
        Skip to content
        [browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0) #91528
        Closed
        #91589
        Closed
        [browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0)#91528
        #91589
        Assignees
        pavelsavara
        Labels
        arch-wasmWebAssembly architecturearea-System.Runtime.InteropServices.JavaScriptos-browserBrowser variant of arch-wasm
        Milestone
        8.0.0
        Description
        @Tarun047
        Tarun047
        opened on Sep 4, 2023
        Description
        Hi,
        
I am facing a weird crash when using .NET 8 Latest Preview for targeting WASM Browser (AOT build).
        
The bug is observed in the following conditions.
        
The bug came out while benchmarking the performance of JS and .NET AOT Wasm.
        
When running a React Application, that uses web workers.
        
The idea is to let user select a file and to compress it using .NET WASM code.
        
Because this is a heavy task, a web worker is used to delegate the task to .NET WASM compression layer.
        
The Web App works fine with small files < 5MB.
        
But If we chose to go with larger files, the compression still succeeds (ofc until we hit OOM) but the .NET runtime exits abruptly with the following weird stack trace if we use files >10MB
        Reproduction Steps
        A repository to reproduce the issue is can he found here dotnet-wasm-react.
        Inorder to reproduce this issue,
        1. Have the .NET 8.0.100-preview.7.23376.3 SDK and also install the wasm-tools, wasm-experimental workloads.
        2. Checkout the repository and perform the following actions:
          
Publish the compress.csproj by running
          dotnet publish -c Release
          
Copy the outputs of /bin/Release/net8.0/browser-wasm/AppBundle/ to compressy-frontend/public/vendor
        3. From the compressy-frontend folder,
          
Install npm dependencies by running npm install and start the webpack dev server by running npm run dev
        4. Use a browser and navigate to http://localhost:8080 and keep the browser console window in browser dev tools open select the choose file button next to WASM .NET Compress and select any large file (>10MB preferably) in file chooser.
        5. check the console output for failure stack trace.
        Expected behavior
        The .NET WASM AOT runtime does not abruptly exit.
        Actual behavior
        The .NET WASM AOT Run time exits with following weird stack trace which I suspect is due to a possible stack corruption.
        [Error] MONO_WASM: {"name":"ExitStatus","message":"Program terminated with exit(undefined)","stack":
"H@http://localhost:8080/vendor/_framework/dotnet.js:3:9846
@http://localhost:8080/vendor/_framework/dotnet.runtime.js:3:203721
_proc_exit@http://localhost:8080/vendor/_framework/dotnet.native.js:8:73946
exitJS@http://localhost:8080/vendor/_framework/dotnet.native.js:8:74058
maybeExit@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89407
Ko@http://localhost:8080/vendor/_framework/dotnet.runtime.js:3:56101
callUserCallback@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89507
@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89634","silent":true}
l (dotnet.js:3:673)
(anonymous function) (dotnet.js:3:10723)
H (dotnet.js:3:10910)
(anonymous function) (dotnet.runtime.js:3:203722)
_proc_exit (dotnet.native.js:8:73947)
exitJS (dotnet.native.js:8:74059)
maybeExit (dotnet.native.js:8:89408)
Ko (dotnet.runtime.js:3:56102)
callUserCallback (dotnet.native.js:8:89508)
(anonymous function) (dotnet.native.js:8:89635)

        Regression?
        The issue doesn't happen in .NET 7 WASM AOT builds
        Known Workarounds
        I haven't found a way to make this work
        Configuration
        Version: .NET 8.0.100-preview.7.23376.3
        
OS: Reproducible on Mac OS X, Windows.
        
Architecture: ARM64, X64
        
Browsers: Safari, Firefox, Chrome
        Other information
        No response
        Metadata
        Metadata
        Assignees
        Labels
        arch-wasmWebAssembly architecturearea-System.Runtime.InteropServices.JavaScriptos-browserBrowser variant of arch-wasm
        Type
        No type
        Projects
        No projects
          Milestone
          Relationships
          None yet
          Development
          No branches or pull requests
          Issue actions
          
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
[browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0) · Issue #91528 · dotnet/runtime · GitHub
          Skip to content
          [browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0) #91528
          Closed
          #91589
          Closed
          [browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0)#91528
          #91589
          Assignees
          pavelsavara
          Labels
          arch-wasmWebAssembly architecturearea-System.Runtime.InteropServices.JavaScriptos-browserBrowser variant of arch-wasm
          Milestone
          8.0.0
          Description
          @Tarun047
          Tarun047
          opened on Sep 4, 2023
          Description
          Hi,
          
I am facing a weird crash when using .NET 8 Latest Preview for targeting WASM Browser (AOT build).
          
The bug is observed in the following conditions.
          
The bug came out while benchmarking the performance of JS and .NET AOT Wasm.
          
When running a React Application, that uses web workers.
          
The idea is to let user select a file and to compress it using .NET WASM code.
          
Because this is a heavy task, a web worker is used to delegate the task to .NET WASM compression layer.
          
The Web App works fine with small files < 5MB.
          
But If we chose to go with larger files, the compression still succeeds (ofc until we hit OOM) but the .NET runtime exits abruptly with the following weird stack trace if we use files >10MB
          Reproduction Steps
          A repository to reproduce the issue is can he found here dotnet-wasm-react.
          Inorder to reproduce this issue,
          1. Have the .NET 8.0.100-preview.7.23376.3 SDK and also install the wasm-tools, wasm-experimental workloads.
          2. Checkout the repository and perform the following actions:
            
Publish the compress.csproj by running
            dotnet publish -c Release
            
Copy the outputs of /bin/Release/net8.0/browser-wasm/AppBundle/ to compressy-frontend/public/vendor
          3. From the compressy-frontend folder,
            
Install npm dependencies by running npm install and start the webpack dev server by running npm run dev
          4. Use a browser and navigate to http://localhost:8080 and keep the browser console window in browser dev tools open select the choose file button next to WASM .NET Compress and select any large file (>10MB preferably) in file chooser.
          5. check the console output for failure stack trace.
          Expected behavior
          The .NET WASM AOT runtime does not abruptly exit.
          Actual behavior
          The .NET WASM AOT Run time exits with following weird stack trace which I suspect is due to a possible stack corruption.
          [Error] MONO_WASM: {"name":"ExitStatus","message":"Program terminated with exit(undefined)","stack":
"H@http://localhost:8080/vendor/_framework/dotnet.js:3:9846
@http://localhost:8080/vendor/_framework/dotnet.runtime.js:3:203721
_proc_exit@http://localhost:8080/vendor/_framework/dotnet.native.js:8:73946
exitJS@http://localhost:8080/vendor/_framework/dotnet.native.js:8:74058
maybeExit@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89407
Ko@http://localhost:8080/vendor/_framework/dotnet.runtime.js:3:56101
callUserCallback@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89507
@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89634","silent":true}
l (dotnet.js:3:673)
(anonymous function) (dotnet.js:3:10723)
H (dotnet.js:3:10910)
(anonymous function) (dotnet.runtime.js:3:203722)
_proc_exit (dotnet.native.js:8:73947)
exitJS (dotnet.native.js:8:74059)
maybeExit (dotnet.native.js:8:89408)
Ko (dotnet.runtime.js:3:56102)
callUserCallback (dotnet.native.js:8:89508)
(anonymous function) (dotnet.native.js:8:89635)

          Regression?
          The issue doesn't happen in .NET 7 WASM AOT builds
          Known Workarounds
          I haven't found a way to make this work
          Configuration
          Version: .NET 8.0.100-preview.7.23376.3
          
OS: Reproducible on Mac OS X, Windows.
          
Architecture: ARM64, X64
          
Browsers: Safari, Firefox, Chrome
          Other information
          No response
          Metadata
          Metadata
          Assignees
          Labels
          arch-wasmWebAssembly architecturearea-System.Runtime.InteropServices.JavaScriptos-browserBrowser variant of arch-wasm
          Type
          No type
          Projects
          No projects
            Milestone
            Relationships
            None yet
            Development
            No branches or pull requests
            Issue actions
            
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
[browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0) · Issue #91528 · dotnet/runtime · GitHub
            Skip to content
            [browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0) #91528
            Closed
            #91589
            Closed
            [browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0)#91528
            #91589
            Assignees
            pavelsavara
            Labels
            arch-wasmWebAssembly architecturearea-System.Runtime.InteropServices.JavaScriptos-browserBrowser variant of arch-wasm
            Milestone
            8.0.0
            Description
            @Tarun047
            Tarun047
            opened on Sep 4, 2023
            Description
            Hi,
            
I am facing a weird crash when using .NET 8 Latest Preview for targeting WASM Browser (AOT build).
            
The bug is observed in the following conditions.
            
The bug came out while benchmarking the performance of JS and .NET AOT Wasm.
            
When running a React Application, that uses web workers.
            
The idea is to let user select a file and to compress it using .NET WASM code.
            
Because this is a heavy task, a web worker is used to delegate the task to .NET WASM compression layer.
            
The Web App works fine with small files < 5MB.
            
But If we chose to go with larger files, the compression still succeeds (ofc until we hit OOM) but the .NET runtime exits abruptly with the following weird stack trace if we use files >10MB
            Reproduction Steps
            A repository to reproduce the issue is can he found here dotnet-wasm-react.
            Inorder to reproduce this issue,
            1. Have the .NET 8.0.100-preview.7.23376.3 SDK and also install the wasm-tools, wasm-experimental workloads.
            2. Checkout the repository and perform the following actions:
              
Publish the compress.csproj by running
              dotnet publish -c Release
              
Copy the outputs of /bin/Release/net8.0/browser-wasm/AppBundle/ to compressy-frontend/public/vendor
            3. From the compressy-frontend folder,
              
Install npm dependencies by running npm install and start the webpack dev server by running npm run dev
            4. Use a browser and navigate to http://localhost:8080 and keep the browser console window in browser dev tools open select the choose file button next to WASM .NET Compress and select any large file (>10MB preferably) in file chooser.
            5. check the console output for failure stack trace.
            Expected behavior
            The .NET WASM AOT runtime does not abruptly exit.
            Actual behavior
            The .NET WASM AOT Run time exits with following weird stack trace which I suspect is due to a possible stack corruption.
            [Error] MONO_WASM: {"name":"ExitStatus","message":"Program terminated with exit(undefined)","stack":
"H@http://localhost:8080/vendor/_framework/dotnet.js:3:9846
@http://localhost:8080/vendor/_framework/dotnet.runtime.js:3:203721
_proc_exit@http://localhost:8080/vendor/_framework/dotnet.native.js:8:73946
exitJS@http://localhost:8080/vendor/_framework/dotnet.native.js:8:74058
maybeExit@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89407
Ko@http://localhost:8080/vendor/_framework/dotnet.runtime.js:3:56101
callUserCallback@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89507
@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89634","silent":true}
l (dotnet.js:3:673)
(anonymous function) (dotnet.js:3:10723)
H (dotnet.js:3:10910)
(anonymous function) (dotnet.runtime.js:3:203722)
_proc_exit (dotnet.native.js:8:73947)
exitJS (dotnet.native.js:8:74059)
maybeExit (dotnet.native.js:8:89408)
Ko (dotnet.runtime.js:3:56102)
callUserCallback (dotnet.native.js:8:89508)
(anonymous function) (dotnet.native.js:8:89635)

            Regression?
            The issue doesn't happen in .NET 7 WASM AOT builds
            Known Workarounds
            I haven't found a way to make this work
            Configuration
            Version: .NET 8.0.100-preview.7.23376.3
            
OS: Reproducible on Mac OS X, Windows.
            
Architecture: ARM64, X64
            
Browsers: Safari, Firefox, Chrome
            Other information
            No response
            Metadata
            Metadata
            Assignees
            Labels
            arch-wasmWebAssembly architecturearea-System.Runtime.InteropServices.JavaScriptos-browserBrowser variant of arch-wasm
            Type
            No type
            Projects
            No projects
              Milestone
              Relationships
              None yet
              Development
              No branches or pull requests
              Issue actions
              
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
[browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0) · Issue #91528 · dotnet/runtime · GitHub
              Skip to content
              [browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0) #91528
              Closed
              #91589
              Closed
              [browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0)#91528
              #91589
              Assignees
              pavelsavara
              Labels
              arch-wasmWebAssembly architecturearea-System.Runtime.InteropServices.JavaScriptos-browserBrowser variant of arch-wasm
              Milestone
              8.0.0
              Description
              @Tarun047
              Tarun047
              opened on Sep 4, 2023
              Description
              Hi,
              
I am facing a weird crash when using .NET 8 Latest Preview for targeting WASM Browser (AOT build).
              
The bug is observed in the following conditions.
              
The bug came out while benchmarking the performance of JS and .NET AOT Wasm.
              
When running a React Application, that uses web workers.
              
The idea is to let user select a file and to compress it using .NET WASM code.
              
Because this is a heavy task, a web worker is used to delegate the task to .NET WASM compression layer.
              
The Web App works fine with small files < 5MB.
              
But If we chose to go with larger files, the compression still succeeds (ofc until we hit OOM) but the .NET runtime exits abruptly with the following weird stack trace if we use files >10MB
              Reproduction Steps
              A repository to reproduce the issue is can he found here dotnet-wasm-react.
              Inorder to reproduce this issue,
              1. Have the .NET 8.0.100-preview.7.23376.3 SDK and also install the wasm-tools, wasm-experimental workloads.
              2. Checkout the repository and perform the following actions:
                
Publish the compress.csproj by running
                dotnet publish -c Release
                
Copy the outputs of /bin/Release/net8.0/browser-wasm/AppBundle/ to compressy-frontend/public/vendor
              3. From the compressy-frontend folder,
                
Install npm dependencies by running npm install and start the webpack dev server by running npm run dev
              4. Use a browser and navigate to http://localhost:8080 and keep the browser console window in browser dev tools open select the choose file button next to WASM .NET Compress and select any large file (>10MB preferably) in file chooser.
              5. check the console output for failure stack trace.
              Expected behavior
              The .NET WASM AOT runtime does not abruptly exit.
              Actual behavior
              The .NET WASM AOT Run time exits with following weird stack trace which I suspect is due to a possible stack corruption.
              [Error] MONO_WASM: {"name":"ExitStatus","message":"Program terminated with exit(undefined)","stack":
"H@http://localhost:8080/vendor/_framework/dotnet.js:3:9846
@http://localhost:8080/vendor/_framework/dotnet.runtime.js:3:203721
_proc_exit@http://localhost:8080/vendor/_framework/dotnet.native.js:8:73946
exitJS@http://localhost:8080/vendor/_framework/dotnet.native.js:8:74058
maybeExit@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89407
Ko@http://localhost:8080/vendor/_framework/dotnet.runtime.js:3:56101
callUserCallback@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89507
@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89634","silent":true}
l (dotnet.js:3:673)
(anonymous function) (dotnet.js:3:10723)
H (dotnet.js:3:10910)
(anonymous function) (dotnet.runtime.js:3:203722)
_proc_exit (dotnet.native.js:8:73947)
exitJS (dotnet.native.js:8:74059)
maybeExit (dotnet.native.js:8:89408)
Ko (dotnet.runtime.js:3:56102)
callUserCallback (dotnet.native.js:8:89508)
(anonymous function) (dotnet.native.js:8:89635)

              Regression?
              The issue doesn't happen in .NET 7 WASM AOT builds
              Known Workarounds
              I haven't found a way to make this work
              Configuration
              Version: .NET 8.0.100-preview.7.23376.3
              
OS: Reproducible on Mac OS X, Windows.
              
Architecture: ARM64, X64
              
Browsers: Safari, Firefox, Chrome
              Other information
              No response
              Metadata
              Metadata
              Assignees
              Labels
              arch-wasmWebAssembly architecturearea-System.Runtime.InteropServices.JavaScriptos-browserBrowser variant of arch-wasm
              Type
              No type
              Projects
              No projects
                Milestone
                Relationships
                None yet
                Development
                No branches or pull requests
                Issue actions
                
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();
[browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0) · Issue #91528 · dotnet/runtime · GitHub
                Skip to content
                [browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0) #91528
                Closed
                #91589
                Closed
                [browser] ENVIRONMENT_IS_WEB is false when dotnet started on worker, leads to exit(0)#91528
                #91589
                Assignees
                pavelsavara
                Labels
                arch-wasmWebAssembly architecturearea-System.Runtime.InteropServices.JavaScriptos-browserBrowser variant of arch-wasm
                Milestone
                8.0.0
                Description
                @Tarun047
                Tarun047
                opened on Sep 4, 2023
                Description
                Hi,
                
I am facing a weird crash when using .NET 8 Latest Preview for targeting WASM Browser (AOT build).
                
The bug is observed in the following conditions.
                
The bug came out while benchmarking the performance of JS and .NET AOT Wasm.
                
When running a React Application, that uses web workers.
                
The idea is to let user select a file and to compress it using .NET WASM code.
                
Because this is a heavy task, a web worker is used to delegate the task to .NET WASM compression layer.
                
The Web App works fine with small files < 5MB.
                
But If we chose to go with larger files, the compression still succeeds (ofc until we hit OOM) but the .NET runtime exits abruptly with the following weird stack trace if we use files >10MB
                Reproduction Steps
                A repository to reproduce the issue is can he found here dotnet-wasm-react.
                Inorder to reproduce this issue,
                1. Have the .NET 8.0.100-preview.7.23376.3 SDK and also install the wasm-tools, wasm-experimental workloads.
                2. Checkout the repository and perform the following actions:
                  
Publish the compress.csproj by running
                  dotnet publish -c Release
                  
Copy the outputs of /bin/Release/net8.0/browser-wasm/AppBundle/ to compressy-frontend/public/vendor
                3. From the compressy-frontend folder,
                  
Install npm dependencies by running npm install and start the webpack dev server by running npm run dev
                4. Use a browser and navigate to http://localhost:8080 and keep the browser console window in browser dev tools open select the choose file button next to WASM .NET Compress and select any large file (>10MB preferably) in file chooser.
                5. check the console output for failure stack trace.
                Expected behavior
                The .NET WASM AOT runtime does not abruptly exit.
                Actual behavior
                The .NET WASM AOT Run time exits with following weird stack trace which I suspect is due to a possible stack corruption.
                [Error] MONO_WASM: {"name":"ExitStatus","message":"Program terminated with exit(undefined)","stack":
"H@http://localhost:8080/vendor/_framework/dotnet.js:3:9846
@http://localhost:8080/vendor/_framework/dotnet.runtime.js:3:203721
_proc_exit@http://localhost:8080/vendor/_framework/dotnet.native.js:8:73946
exitJS@http://localhost:8080/vendor/_framework/dotnet.native.js:8:74058
maybeExit@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89407
Ko@http://localhost:8080/vendor/_framework/dotnet.runtime.js:3:56101
callUserCallback@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89507
@http://localhost:8080/vendor/_framework/dotnet.native.js:8:89634","silent":true}
l (dotnet.js:3:673)
(anonymous function) (dotnet.js:3:10723)
H (dotnet.js:3:10910)
(anonymous function) (dotnet.runtime.js:3:203722)
_proc_exit (dotnet.native.js:8:73947)
exitJS (dotnet.native.js:8:74059)
maybeExit (dotnet.native.js:8:89408)
Ko (dotnet.runtime.js:3:56102)
callUserCallback (dotnet.native.js:8:89508)
(anonymous function) (dotnet.native.js:8:89635)

                Regression?
                The issue doesn't happen in .NET 7 WASM AOT builds
                Known Workarounds
                I haven't found a way to make this work
                Configuration
                Version: .NET 8.0.100-preview.7.23376.3
                
OS: Reproducible on Mac OS X, Windows.
                
Architecture: ARM64, X64
                
Browsers: Safari, Firefox, Chrome
                Other information
                No response
                Metadata
                Metadata
                Assignees
                Labels
                arch-wasmWebAssembly architecturearea-System.Runtime.InteropServices.JavaScriptos-browserBrowser variant of arch-wasm
                Type
                No type
                Projects
                No projects
                  Milestone
                  Relationships
                  None yet
                  Development
                  No branches or pull requests
                  Issue actions