Chrome launched from service freeze with ^#^#^#^# output - google-chrome

We are running a Chrome from a linux service and sometimes the instance of chrome freeze (and all the computer too) unexpectedly with the following error :
May 27 21:57:51 Q190N-prototype google-chrome[24703]: [24703:24703:0527/215751.950576:INFO:CONSOLE(342)] "nextVideo()", source: http://192.168.22.16/animatic/static/js/player/index.js?ver=1558013787 (342)
May 27 21:57:51 Q190N-prototype google-chrome[24703]: [24703:24703:0527/215751.952062:INFO:CONSOLE(342)] "nextVideo()", source: http://192.168.22.16/animatic/static/js/player/index.js?ver=1558013787 (342)
May 27 21:58:03 Q190N-prototype google-chrome[24703]: [24703:24703:0527/215803.050265:INFO:CONSOLE(342)] "nextVideo()", source: http://192.168.22.16/animatic/static/js/player/index.js?ver=1558013787 (342)
May 27 21:58:03 Q190N-prototype google-chrome[24703]: [24703:24703:0527/215803.051856:INFO:CONSOLE(342)] "nextVideo()", source: http://192.168.22.16/animatic/static/js/player/index.js?ver=1558013787 (342)
^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#
^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#
^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#
^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#May 28 10:33:49 Q190N
-prototype lvm[213]: 2 logical volume(s) in volume group "debian-vg" monitored
May 28 10:33:49 Q190N-prototype keyboard-setup.sh[211]: Impossible d'ouvrir le fichier /tmp/tmpkbd.k7WSzt
Any idea in order to solve this problem is welcome...

You probably have a problem on index.js or another imported script.
There are a list of possibilities, but most times freeze is caused by while(true) or long loops.
If this is the problem, try:
You can break the calculation up into pieces and do a piece at a time on a
setTimeout(). On each setTimeout() call, the browser will be free to serve other
events and will keep the page alive and responive. When you finish the last piece of the calculation, you can then carry out the result.
You can run the calculation in the background using a webworker in modern browsers. When the calcuation is done in the webworker, it sends a message back to the main thread and you can then update the DOM with the result.
This answer might help: https://stackoverflow.com/a/49961782/11578778
I hope this helps!
Brhaka

This seems like a buffer overflow to me, Q190N-prototype keyboard-setup.sh is the linux keyboard map and stores the map file in /tmp.
/tmp/tmpkbd.k7WSz seems like the map file for keyboard binding.
^#^#^#^#^#^#^#^#^#^#^#^# is definitely garbage from memory. Now the question is what are how is your player jumping to this address. Is it waiting for some keyboard input at some point of time while playing media. May be at the end when to play next or something.
Its either a permission or file not found issue
try it with sudo once and see if you can reproduce the error

Related

Exception handling with Realbrowserlocusts

In using realbrowserlocusts class it appears that I'm limited in any exception handling.
The only reference that partially works is: self.client.wait.until(EC.visibility_of_element_located ....
In a failed condition where the element is not found the script simply starts over again. With the script I'm working with I need to maintain a solid session state; I need to throw and exception(report an error), log the user out and then let the script start over again. I've been testing out the behavior with the locust.py script that Nick B. created with several approaches to "try, except" and they work running without realbrowserlocusts (selenium only) but with it the execution just stops.
Any examples would be greatly appreciated.
In its current format I've been able to run 3x the amount of a browser-based load per/agent/slave than our commercial tool. My goal is to replace it with a locust/selenium approach.
locust-plugins's WebdriverUser has a little bit better exception handling I think. A failure to find an element will log a failed request and if you use RescheduleTaskOnFail (as in the the example) it will restart the task when that happens.
https://github.com/SvenskaSpel/locust-plugins/blob/master/examples/webdriver_ex.py

Sync multiple process traces for chrome://tracing

I have multiple process producing traces in separate files, so I want to sync them to display on a single timeline. Let's say I have 2 files.
agent_service_trace.json:
{"traceEvents":[
{"cat":"AgentService","pid":6876,"tid":6868,"ts":0,"ph":"X","name":"wWinMain","args":{},"dur":448701329},
{"cat":"","pid":6876,"tid":6868,"ts":3,"ph":"M","name":"process_name","args":{"name":"AgentService"}},
{"cat":"","pid":6876,"tid":6868,"ts":20,"ph":"M","name":"thread_name","args":{"name":"Main thread"}}
]}
agent_host_trace.json:
{"traceEvents":[
{"cat":"AgentHost","pid":6564,"tid":6440,"ts":0,"ph":"X","name":"wWinMain","args":{},"dur":448701329},
{"cat":"","pid":6564,"tid":6440,"ts":5,"ph":"M","name":"process_name","args":{"name":"AgentHost"}},
{"cat":"","pid":6564,"tid":6440,"ts":10,"ph":"M","name":"thread_name","args":{"name":"Main host"}}
]}
They are started with slight difference in time, from few seconds up to few minutes. When I'm combining them one by one, since ts arg is time from the beginning of process tracing, they looks like were started at the same point in time.
From the tracing documentation and clock sync addition especially, I'v found that Clock Sync event was created to handle multiple trace logs produced by different tracing agents and synchronize their clock domains. But as I know chrome://tracing doesn't support multiple files at time. The thing I'v tried so far, were adding clock_sync to events:
{"traceEvents":[
{"ts":0,"ph":"c","name":"clock_sync","args":{"sync_id":"guid0","sync_ts":0}},
{"cat":"AgentService","pid":6876,"tid":6868,"ts":0,"ph":"X","name":"wWinMain","args":{},"dur":448701329},
{"cat":"","pid":6876,"tid":6868,"ts":3,"ph":"M","name":"process_name","args":{"name":"AgentService"}},
{"cat":"","pid":6876,"tid":6868,"ts":20,"ph":"M","name":"thread_name","args":{"name":"Main thread"}},
{"ts":0,"ph":"c","name":"clock_sync","args":{"sync_id":"guid1","sync_ts":30000}},
{"cat":"AgentHost","pid":6564,"tid":6440,"ts":0,"ph":"X","name":"wWinMain","args":{},"dur":448701329},
{"cat":"","pid":6564,"tid":6440,"ts":5,"ph":"M","name":"process_name","args":{"name":"AgentHost"}},
{"cat":"","pid":6564,"tid":6440,"ts":10,"ph":"M","name":"thread_name","args":{"name":"Main host"}}
]}
I really don't know how this supposed to work, I'v tried to add sync_id as arg to events, also tried add pid as arg to clock_sync event. All of mine manipulations had no effect. I though there must be a link inbetween events and clock_sync's sync_id, but unable to find any info on this. I would appreciate any help.

Web page is really slow in Chrome when inspector is open but *not* profiling

In my Angular application, after introducing some more heavy usage of ngxs, I see my application has been come very slow when the inspector is open, but not when the profiler is running.
This has made it a little hard to figure out what's going on, but using the old conosle.profile method (adding an entry to Chrome's old profiler), I've narrowed it down a little - but I'm not at all more informed now than I was - just more confused.
So here's to hoping someone here can help me out!
I have some screenshots from the profiling to share, but unfortunately not much else.
First, a screenshot from the profile chart:
As you can see, there's a looooong time, where apparently nothing is really happening. Note in the console, that the bottom method (startObserving) only takes .12ms (according to console.time)
Going up the tree a few steps, we find Handsontable - this is what the function looks like, and some timings associated:
function Handsontable(rootElement, userSettings) {
console.time('Handsontable total time');
console.time('Handsontable create instance');
var instance = new _core2.default(rootElement, userSettings || {}, _rootInstance.rootInstanceSymbol);
console.timeEnd('Handsontable create instance');
console.time('Handsontable init instance');
instance.init();
console.timeEnd('Handsontable init instance');
console.timeEnd('Handsontable total time');
return instance;
}
// Timer outputs:
// This looks OK
Handsontable create instance: 10.864990234375ms
// Also this
Handsontable init instance: 1462.807861328125ms
// Wow, what??
Handsontable total time: 52664.875ms
It looks like the 2 methods called in the Handsontable constructor/function have a total run-time of <1500ms, but the total execution time is more than 52 seconds.
What in the world can be happening in those ~50 seconds of - as I see it - idle time?
Any help is really welcome, hints, suggestions, help to better debug!
Note: In Firefox, this is not an issue. I've tried in Chromium 67, 68 and 69 too - same issue. It's a problem in Chrome across all platforms (tested in Windows 10, Ubuntu 16,17 and MacOS latest-1,latest)

Captured audio buffers are all silent on Windows Phone 8

I'm trying to capture audio using WASAPI. My code is largely based on the ChatterBox VoIP sample app. I'm getting audio buffers, but they are all silent (flagged AUDCLNT_BUFFERFLAGS_SILENT).
I'm using Visual Studio Express 2012 for Windows Phone. Running on the emulator.
I had the exact same problem and managed to reproduce it in the ChatterBox sample app if I set Visual Studio to native debugging and at any point stepped through the code.
Also, closing the App without going through the "Stop" procedure and stopping the AudioClient will require you to restart the emulator/device before being able to capture audio data again.
It nearly drove me nuts before I figured out the before mentioned problems but I finally got it working.
So..
1. Be sure to NOT do native debugging
2. Always call IAudioClient->Stop(); before terminating the App.
3. Make sure you pass the correct parameters to IAudioClient->Initialize();
I've included a piece of code that works 100% of the time for me. I've left out error checking for clarity..
LPCWSTR pwstrDefaultCaptureDeviceId =
GetDefaultAudioCaptureId(AudioDeviceRole::Communications);
HRESULT hr = ActivateAudioInterface(pwstrDefaultCaptureDeviceId,
__uuidof(IAudioClient2), (void**)&m_pAudioClient);
hr = m_pAudioClient->GetMixFormat(&m_pwfx);
m_frameSizeInBytes = (m_pwfx->wBitsPerSample / 8) * m_pwfx->nChannels;
hr = m_pAudioClient->Initialize(AUDCLNT_SHAREMODE_SHARED,
AUDCLNT_STREAMFLAGS_NOPERSIST | AUDCLNT_STREAMFLAGS_EVENTCALLBACK,
latency * 10000, 0, m_pwfx, NULL);
hr = m_pAudioClient->SetEventHandle(m_hCaptureEvent);
hr = m_pAudioClient->GetService(__uuidof(IAudioCaptureClient),
(void**)&m_pCaptureClient);
And that's it.. Before calling this code I've started a worker thread that will listen to m_hCaptureEvent and call IAudioCaptureClient->GetBuffer(); whenever the capture event is triggered.
Of course using Microsoft.XNA.Audio.Microphone works fine to, but it's not always an option to reference the XNA framework.. :)
It was a really annoying problem which waste about 2 complete days of mine.My problem was solved by setting AudioClientProperties.eCatagory to AudioCategory_Communications instead of AudioCategory_Other.
After this long try and error period I am not sure that the problem won't repeat in the future because the API doesn't act very stable and every run may return a different result.
Edit:Yeah my guess was true.Restarting the wp emulator makes the buffer silent again.But changing the AudioClientProperties.eCatagory back to AudioCategory_Other again solve it.I still don't know what is wrong with it and what is the final solution.
Again I encounter the same problem and this time commenting (removing) the
properties.eCategory = AudioCategory_Communications;
solve the problem.
I can add my piece of advice for Windows Phone 8.1.
I made the following experiment.
Open capture device. Buffers are not silent.
Open render device with AudioDeviceRole::Communications. Buffers immediately go silent.
Close render device. Buffers are not silent.
Then I opened capture device with AudioDeviceRole::Communications and capture device works fine all the time.
For Windows 10 capture device works all the time, no matter if you open it with AudioDeviceRole::Communications or not.
I've had the same problem. It seems like you can either use only AudioCategory_Other or create an instance of VoipPhoneCall and use only AudioCategory_Communications.
So the solution in my case was to use AudioCategory_Communications and create an outgoing VoipPhoneCall. You should implement the background agents as in Chatterbox VoIP sample app for the VoipCallCoordinator to work .

How do BundleActivator, ManagedService, and my application interact on start/stop?

I had a non-OSGi application. To convert it to OSGi, I first bundled it up and gave it a simple BundleActivator. The activator's start() started up a thread of what used to be the main() of my app (and is now a Runnable), and remembered that thread. The activator's stop() interrupted that thread, and waited for it to end (via join()), then returned. This all seemed to be working fine.
As a next step in the OSGiification process, I am now trying to use OSGi configuration management instead of the Properties-based configuration that the application used to use. So I am adding in a ManagedService in addition to the Activator.
But it's no longer clear to me how I am supposed to start and stop my application; examples that I've seen are only serving to confuse me. Specifically, here:
http://felix.apache.org/site/apache-felix-config-admin.html
They no longer seem to do any real starting of the application in BundleActivator.start(). Instead, they just register a ManagedService to receive configuration. So I'm guessing maybe I start up the app's main thread when I receive configuration, in the ManagedService? They don't show it - the ManagedService's updated() just has vague comments saying to "apply configuration from config admin" when it is passed a non-null Dictionary.
So then I look here:
http://blog.osgi.org/2010/06/how-to-use-config-admin.html
In there, it seems like maybe they're doing what I guessed. They seem to have moved the actual app from BundleActivator to ManagedService, and are dealing with starting it when updated() receives non-null configuration, stopping it first if it's already started.
But now what about when the BundleActivator's stop() gets called?
Back on the first example page that I mentioned above, they unregister the ManagedService. On the second example page, they don't show what they do.
So I'm guessing maybe unregistering the ManagedService will cause null configuration to be sent to ManagedService.updated(), at which point I can interrupte the app thread, wait for it to end, and then return?
I suspect that I'm thoroughly incorrect, but I don't know what the "real" way to do this is. Thanks in advance for any help.
BundleActivator (BA) and ManagedService (MS) are callbacks to your bundle. BundleActivator is for the active state of your bundle. BA.start is when you bundle is being started and BA.stop is when it is being stopped. MS is called to provide your bundle a configuration, if there is one, or notify you there is no configuration.
So in BA.start, you register your MS service and return. When MS is called (on some other thread), you will either receive your configuration or be told there is no configuration and you can act accordingly (start app, etc.)
Your MS can also be called at anytime to advice of the modification or deletion of your configuration and you should act accordingly (i.e. adjust your app behavior).
When you are called at BA.stop, you need to stop your app. You can unregister the MS or let the framework do it for you as part of normal bundle stop processing.