We are running chromium 83 on an embedded system and experience some random tab crashes.
Is it possible to directly reload a tab in chromium, if it crashes (without showing the "Aw snap!" page)?
We're currently trying to patch the source code to get it working and those were our approaches so far.
(both in sad_tab_helper.cc -> SadTabHelper::RenderProcessGone()
Approach 1:
if (SadTab::ShouldShow(status)) {
web_contents()->GetController().Reload(content::ReloadType::NORMAL, true);
}
Approach 2:
if (SadTab::ShouldShow(status)) {
content::RunOrPostTaskOnThread(
FROM_HERE,
content::BrowserThread::ID::UI,
base::BindOnce(
[](content::WebContents* contents) {
contents->GetController().Reload(content::ReloadType::NORMAL, true);
},
std::move(web_contents())));
}
Both changes finally lead to crash of the entire browser.
It seems that chromium tries to reload the page but as said, it then crashes. The log we get are:
[1663:1671:0321/090914.211931:VERBOSE1:network_delegate.cc(32)] NetworkDelegate::NotifyBeforeURLRequest: http://127.0.0.1/login
[1663:1671:0321/090919.082378:ERROR:broker_posix.cc(40)] Recvmsg error: Connection reset by peer (104)
After that the entire browser crashes. Is there a way to do what we want or are we on a dead end here?
The second approach is suboptimal, SadTabHelper::RenderProcessGone only runs on UI.
Initiating navigation while handling notifications from any WebContentsObserver (SadTabHelper is a WebContentsObserver) must be avoided. It leads to problems. The both approaches attempt to do this. I suppose using base::PostTask instead of content::RunOrPostTaskOnThread should help.
if (SadTab::ShouldShow(status)) {
base::PostTask(
FROM_HERE,
{content::BrowserThread::UI},
base::BindOnce(
[](content::WebContents* contents) {
contents->GetController().Reload(content::ReloadType::NORMAL, true);
},
web_contents()));
}
My reputation is not good enough to comment so I can't leave this comment where it should be.
If you come across this particular solution, the required includes are:
#include "base/task_scheduler/post_task.h"
#include "content/public/browser/browser_thread.h"
#include "base/bind.h"
I'm attempting to use sentUserNotification on Android and I get the error below.
Test Failed: No Activity found to handle Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x24000000 pkg=com...****** (has extras) }
Is this something someone here has ran into before? I think my app is set up correctly (e.g. manifest has intent filter) but I'm wondering if there's something else I missed.
I'm on Detox v17.11.4.
I've started a new React Native project and I keep getting the following warning:
Remote debugger is in a background tab which may cause apps to perform slowly. Fix this by foregrounding the tab (or opening it in a separate window).
It's a bit annoying so I wanna know how I can get rid of it? I'm running the debugger in Chrome and I moved it to a seperate window but it did not help.
If you have the Maintain Priority checkbox in the debugger window, try enabling it before you jump to any of the solutions below.
To get rid of the warning in your whole project add the following to your outermost Javascript file (most of the time that's index.js for React Native)
for react-native v0.63+:
Use LogBox:
https://reactnative.dev/docs/debugging#logbox
LogBox.ignoreLogs(['Remote debugger']);
for react-native v0.57 - v0.62:
import { YellowBox } from 'react-native';
YellowBox.ignoreWarnings(['Remote debugger']);
Reference this from the official React Native docs:
https://facebook.github.io/react-native/docs/debugging.html
react-native v0.56 or below:
Add the following early on in your code:
console.ignoredYellowBox = ['Remote debugger'];
Easy, simple and specific to that error. Works for me. Can substitute for any text you want.
this solution is work for me
open/move http://localhost:8081/debugger-ui (default path for remote debugging) on the separate window
maybe that could help :)
You can use React Native Debugger available at https://github.com/jhen0409/react-native-debugger It is a standalone app for debugging React Native apps during development.
Move http://localhost:*****/debugger-ui on the separate window.
Restart Remote JS Debugging.
For me warning went away by checking Maintain Priority Checkbox!
It is because of number of tabs are opened in the browser with React Native Remote Debugger UI tab. I also faced the same issue.
To overcome this warning message you can use any one method from the following:
Open an incognito tab then paste http://localhost:8081/debugger-ui on address bar and press ENTER. Finally reload the app (Command+R).
Close all the tabs in the browser. Keep only 1 tab opened then hit http://locahost:8081/debugger-ui then reload the app (Command+R).
As mentioned by #jakeforaker in one of the comment. The warning went away by simply opening the remote debugger in a separate window instead of a tab in your existing window of your browser (you have to reload your simulator though).
As the warning is saying keeping the remote debugger in the same window as other tabs
may cause apps to perform slowly
So i think simply suppressing warning as mentioned by #kjonsson:- console.ignoredYellowBox = ['Remote debugger']; doesnt seem to be best solution.
Since this commit in March 2017, you can enable the Maintain Priority checkbox. When enabled, it silently plays a base64-encoded .wav file to prevent the debugger's browser tab from entering low-power mode, which can affect websocket performance. This will effectively prevent the warning you describe.
This issue was resolved when I closed all open Chrome windows and started the Remove Debugging again. I had previously had open Chrome windows, so it 'seems' that having them open kills performance.
I think the accepted answer is no longer accurate (at least for React Native v0.57+).
The correct code is now:
import { YellowBox } from 'react-native';
YellowBox.ignoreWarnings(['Remote debugger']);
Reference this from the official React Native docs:
https://facebook.github.io/react-native/docs/debugging.html
I am on Macbook. I fixed this issue by bringing the Debugger window on main desktop, rather than on having it on separate desktop which it thinks is in "Background".
I had the same issue pop up yesterday. Googling it led to this Stack Overflow post. In one of the response (by adriansprod), he suggested:
Chrome debugger in it's own window fixes. But annoying problem
It is likely that your React Native debugger is not in its own Chrome browser window but in a Chrome browser tab. Pulling it out as its own window, as adriansprod suggest, fixed this for me.
The (very annoying) error message is handled by debuggerWorker.js, which sadly doesn't include any configuration options to turn off the message. So for the time being there are no ways you can configure your application to disable the message.
The related code is outlined below (original licence applies):
var visibilityState;
var showVisibilityWarning = (function() {
var hasWarned = false;
return function() {
// Wait until `YellowBox` gets initialized before displaying the warning.
if (hasWarned || console.warn.toString().includes('[native code]')) {
return;
}
hasWarned = true;
console.warn(
'Remote debugger is in a background tab which may cause apps to ' +
'perform slowly. Fix this by foregrounding the tab (or opening it in ' +
'a separate window).'
);
};
})();
As you see, no configuration options are used, the whole thing is scoped off locally (see the above repo link for further details).
I also have faced with same issue about one week ago and finally i have found solution that works excelent for me
It called reactotron, you can find it here - https://github.com/reactotron/reactotron and you can use it to:
* view your application state
* show API requests & responses
* perform quick performance benchmarks
* subscribe to parts of your application state
* display messages similar to console.log
* track global errors with source-mapped stack traces including saga stack traces!
* dispatch actions like a government-run mind control experiment
* hot swap your app's state
* track your sagas
I hope my post was helpful and you never will faced with this tedious warning .
Good luck
I use this in index.js
if (__DEV__) {
console.ignoredYellowBox = [
'Remote debugger',
'Warning: isMounted… is deprecated',
'Module RCTImageLoader'
];
}
I had minimised the "http://localhost:8081/debugger-ui/" window. Just opening it up (un minimising), and reloading the app removed the warning.
there might be chances that Another debugger is already connected to packager.
so close your terminal and debugger google chrome.
if you are using visual studio's package manger then don't start package manager by Mac/other os terminal command.
so close all terminal and stop on going package manger and google chrome debugger.
start the process again.
Similar to Akshay Vijay Jain, mine went away by ticking this box!
I'm trying to ensure that the release build of my MonoTouch app will produce crash logs that I can use, but I'm unable to get any crash logs from the device. Here are the steps I'm taking.
I put some code in my app that would force it to crash when the user touches the screen.
I did a release build and verified that the .dSYM folder is next to the .app folder.
I ran the app on my iPad and touched the screen to make it crash. The app exited instantly.
I did a Sync in iTunes.
I looked under Library\Logs\CrashReporter\MobileDevice[devicename] and [devicename].symbolicated, but there is nothing under there.
I've tried two methods of making the app crash. First way:
SomeObject x = null;
x.SomeFunction();
Second way:
unsafe {
short *p = (short*)0;
for ( int i=0; i < 1000000; i++ )
p[i] = 0;
}
Both methods cause the app to exit instantly, but neither is producing a crash log.
What am I missing here?
It appears that unhandled managed exceptions do not generate a crash log. Could you please file a bug at http://monotouch.net/Support so we can track and fix this issue?
In the mean time you could wrap your Main call in
try {
} catch {}
and log it somewhere and upload it to a web server you have or some such.
I'm working with the ID3 framework in Xcode (which has since disappeared off the face of the web - including google cache!).
I'm testing out an import mp3 feature which allows them to edit the tags as they import them. One of the test cases is a corrupt or invalid mp3 with no proper id3 header. The problem I'm having is that when updating the tags of the invalid mp3 (updateFile:), the ID3 framework attempts to use id3V1Tag.m (I assume it falls back to this if it can't find the v2 tag) and this is where I get the Xcode error (whilst running the program, not building):
Xcode could not locate source file: id3V1Tag.m (line: 299)
Even in a release build this crashes the program, so it's not something I can really ignore.
I've tried putting a try/catch block around it but it's not treated as an exception so doesn't get caught. The function to load the tag data for the file returns a BOOL but it appears this only returns false if the given file doesn't exist, so this doesn't help either.
Current code:
[tagData release];
tagData = [[TagAPI alloc] initWithGenreList:nil];
tagsLoaded = [tagData examineFile:exportPath];
if(tagsLoaded) {
[tagData setTitle:title];
[tagData setArtist:artist];
[tagData setComments:comments];
#try {
[tagData updateFile];
}
#catch (id e){
NSLog(#"h");
}
}
The error you're getting is that Xcode is trying to locate your source file id3V1Tag.m in order to show it during debugging. No code you write will affect this.
If you don't have the id3V1Tag.m source file in your framework distro, there's nothing you can do about this, and there's little to do but ignore it (other than seeing if you can avoid causing it to be requested, like not setting a breakpoint in it, not stepping into it, and not crashing in it).
If you do have it, and are building it, then perhaps you're not building with the right debug information, so you'll have to tell us more about your build setup.
So the problem you're having is that your program is crashing when you attempt to compile id3V1Tag.m or while running the program. I'm a bit confused on that.
If its crashing while running maybe this is an issues with a code file missing from a library? How are you reading the ID3 tag information exactly? Is it through your own code or through a 3rd party library/class.