Re: Firefox 55.* in Windows/Ubuntu - every day CPU 100%/Hangs Up. Please to do something!

[Bob Clary]

On 11/21/17 3:54 AM, Alexey Zvyagin wrote:

Hi!

I made some crashes by hands (crashfirefox.exe) in Windows 7 and in Unix
through kill -ABRT

What are the symptoms? In random moments the Firefox v56.* has only-one
core CPU 100% eating. In Windows 7 (64bit) & Linux (Ubuntu 16.04 LTE 64bit)

Reports are here:

Ubuntu OS:

https://crash-stats.mozilla.com/report/index/0b0e6273-26fb-482e-b033-c91be1171101
https://crash-stats.mozilla.com/report/index/237ae0e4-6eb2-4c8b-87e8-3c2471171101
https://crash-stats.mozilla.com/report/index/7ddfad60-8f3e-4495-a05f-5d6d21171110
https://crash-stats.mozilla.com/report/index/95468eb1-28b2-40f7-8f0c-8a7261171110
https://crash-stats.mozilla.com/report/index/cd310102-c547-486f-bbd3-0b7791171110
https://crash-stats.mozilla.com/report/index/6df179b4-721a-4440-97e5-059d21171110

Windows 7:

https://crash-stats.mozilla.com/report/index/8e172c11-2367-43b1-98f2-128251171113#allthreads

Best regards, Alexey


It may be one of your extensions. Please try safe mode [1] and see if 
you can reproduce the issue with your extensions disabled. If the 
problem is gone then the issue is at least partly due to an extension.


You can find the problematic extension by visiting about:addons and 
selectively disabling each one and restarting Firefox. A binary search 
will help cut down the number of steps, but either way it won't take too 
long.


Then please file a bug [2] with the information you have provided here 
already as well as the contents of about:support and 
about:telemetry#chrome-hangs-tab as well as the results of your search 
for the possibly offending extension(s).


Firefox 55 and 56 are no longer supported. You may want to consider 
upgrading to Firefox 57 if your extensions are supported. "Helping You 
Find Compatible Extensions" [3] may be helpful in upgrading or finding 
replacements for your extensions so that you can upgrade to Firefox 57.


[1] 



[2] 



[3] 


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

FYI - Autophone down for maintenance

[Bob Clary]

Autophone  is going down this 
afternoon for several hours while the devices are being switched to new 
hosts.


bc
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visualizing Crash Data in Bugzilla

[Bob Clary]

This is *way* cool! The historical feedback for the signatures is very 
compelling. I recommend everyone try it out and that we all make sure to 
populate the crash signature.


/bc

On 08/16/2016 02:47 PM, Anthony Hughes wrote:

Hi Platform team,

In case you don't follow planet.mozilla.org I wanted to highlight that I'm
releasing the initial version of my experimental Bugzilla Tweaks add-on,
dubbed Bugzilla Socorro Lens v0.3.

https://ashughes.com/?p=360

In a nutshell, this inserts a graph of aggregate crash data for signatures
listed in the Crash Signature field of a bug report. The visualization is
powered by MetricsGraphics.js and the data is coming from the Socorro
supersearch API.

Feedback welcome!

Cheers



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Mac OS X 10.7 SDK or later now required for Mac builds

[Bob Clary]

On 07/31/2014 11:02 AM, Steven Michaud wrote:



I think this means we can no longer build on OS X 10.6 -- which isn't
a big deal, because I don't believe that's been possible since we
switched to using clang by default (instead of gcc/g++), at
https://bugzilla.mozilla.org/show_bug.cgi?id=733905.


Actually I had been building on 10.6 up until this morning. I've 
switched my builders to 10.9 where it appears all is well and I am able 
to run the builds on 10.6+.


/bc

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Mac OS X 10.7 SDK or later now required for Mac builds

[Bob Clary]

On 08/01/2014 09:27 AM, Ralph Giles wrote:

On 2014-07-31 11:42 AM, Bob Clary wrote:


Actually I had been building on 10.6 up until this morning. I've
switched my builders to 10.9 where it appears all is well and I am able
to run the builds on 10.6+.


Just out of curiousity, are you building against the 10.7 sdk on 10.9,
or against the native libraries, and having it work on 10.6+?

Would be nice to know if 10.9 builds still work on 10.6.



I didn't specify --with-macos-sdk when building on 10.6 previously nor 
when building on 10.9, so native libraries?


Xcode 5.0.2 is installed on the 10.9 machine with the 10.8 and 10.9 
sdks, but I didn't specifically select either.


These builds do run on 10.6.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to shut down Mozilla instance of WebPagetest.

[Bob Clary]

I have been running a custom instance of WebPagetest
(http://www.webpagetest.org/) which tests page loading performance for
different bandwidths for Firefox builds on 32 bit Windows 7.

Due to lack of interest, I would like to shut the system down. If you
do not want the tool to be shut down, please let me know. If no one
expresses interest, I will shut down the system after the end of the
month.

Background

You can run the public WebPagetest tests using the released versions
of Firefox, Chrome or Internet Explorer using the public instance at
(http://webpagetest.org/). I ran several example tests on the public
instance which you can review to get a feeling for what Webpagetest
does.

Firefox native - http://www.webpagetest.org/result/141013_KZ_XVK/
Chrome native - http://www.webpagetest.org/result/141013_NB_XT2/
IE11 native - http://www.webpagetest.org/result/141013_0G_XT7/

These may expire, but you should be able to re-run the tests yourself
if these have already expired.

The Mozilla instance of WebPagetest is available from the Mozilla
VPN. If you do not have access, you can file a Service Desk request to
gain access to http://perf-linux-001.ateam.scl3.mozilla.com/.

You can submit test jobs for any Windows 32bit build from
(http://perf-linux-001.ateam.scl3.mozilla.com/wpt-controller) and view
the full test results from the WebPagetest instance at
(http://perf-linux-001.ateam.scl3.mozilla.com/). You will receive
email notifications as the jobs runs with links to the test results
when each url completes testing. You can test Firefox builds by
providing a url to the Windows 32 bit installer for the build you wish
to test.

The system is configured to support the following bandwidths

3G (1.6 Mbps/768 Kbps 300ms RTT)
56K Dial-Up (49/30 Kbps 120ms RTT)
Broadband (10 Mbps/10 Mbps 90ms RTT)
Cable (5/1 Mbps 28ms RTT)
Classic Mobile (400 Kbps/400 Kbps 300ms RTT)
DSL (1.5 Mbps/384 Kbps 50ms RTT)
FIOS (20/5 Mbps 4ms RTT)
Modern Mobile (1 Mbps/1 Mbps 150ms RTT)
Native Connection (No Traffic Shaping)

and allows testing either a single custom url or one or more of the
following live web sites:

http://cnn.com/
http://www.yahoo.com/
http://www.mozilla.org/
https://www.facebook.com/
https://mail.google.com/mail/u/0/?shva=1#inbox
http://pinterest.com/all/
http://en.wikipedia.org/wiki/Ottoman_Empire
http://www.nytimes.com/

These live web sites have been automatically tested each day with a
Nightly build using the Broadband, Modern Mobile and Classic Mobile
bandwidth settings and the results posted to datazilla at
https://datazilla.mozilla.org/?product=Firefox&repository=mozilla-central&os=WINNT&os_version=6.1

/bc
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Bob Clary]

On 04/17/2015 09:46 AM, Mike Hoye wrote:

On 2015-04-17 12:20 PM, Anne van Kesteren wrote:

On Fri, Apr 17, 2015 at 6:13 PM,   wrote:

As a non-tech person, the only thing I know is https means my browser
runs even slower on DSL.

This has already been addressed earlier in the thread. HTTPS has
negligible performance impact. See e.g.:

   https://istlsfastyet.com/

I don't see where that document speaks to the impact of TLS on caching
proxies, which I'm guessing is the source of the performance hit Andrew
mentions.

It's been a while since I've looked, but in Canada (and probably other
geographically large countries) the telcos/ISP with large exurban/rural
client bases used to use caching proxies a lot.


From my past experience with satellite based connections https was 
appreciably slower than http. I don't know how much of the affect was 
due to the loss of the caching proxy or how much was due to the 
latency+handshake issue. This was also several years ago and I don't 
have experience with the improved networking in Firefox over satellite .


In third world countries, such as the United States, many people in 
rural areas are limited to satellite base connections and may be 
adversely affected by the move to encrypted connections. This isn't to 
say we shouldn't move to encryption, just that the network experience in 
major metropolitan areas isn't indicative of what someone in rural 
Virginia might experience for example.


/bc


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using rust in Gecko. rust-url compatibility

[Bob Clary]

On 04/30/2015 04:08 PM, Chris Hofmann wrote:

check to see if we still have any automated crawlers still running that
could go looking for problems.

give the the folks that run the crawlers an instrumented build, and strong
liquor for best results.

-chofmann


I run a system called Bughunter that scans a subset of the urls 
submitted to the crash reports system in the attempt to reproduce the 
crashes our users see. It runs on Windows 7, OSX 10.{6,8,9} and RHEL6.


If this were to land in Nightly and if it were to produce a fatal 
assertion such as "Assertion failure:..." or "ABORT:..." or even a 
non-fatal ASSERTION, it would automatically be recorded in our webapp [*].


I've also used these vms for other scanning purposes. For example, I 
scanned the top 1 million sites from Alexa over a period in December 
2014 - January 2015 and produced data and files for all Flash files 
discovered for use by the Shumway folks.


So, this is something we could support with Bughunter or a subset of the 
Bughunter vms. Hopefully this will not produce a large number of 
Assertions, since I wouldn't want it to detract from our finding 
security sensitive crashes.


I might need some help in producing these Frankenbuilds on all three 
platforms.


/bc

[*] The urls tested come from our users via the Crash Reports system and 
are privacy sensitive. The urls also frequently contain extreme NSFW 
content and have in the past contained illegal content which may be 
harmful to the viewer.



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Android Hardware testing on Try only available via mach try fuzzy

[Bob Clary]

To help cut down on inadvertent invocations of tests on the limited
Android hardware, I've landed Bug 1515599 - Prevent android hardware
tests from running when using try option syntax on mozilla-inbound.

If you actually want to run tests on Android hardware, you must use
mach try fuzzy.

See

for details on installing and running mach try fuzzy.

You can easily see the available tests via

$ ./mach try fuzzy --no-push --full --query "android-hw"
Commit message:
Fuzzy query=android-hw

Pushed via `mach try fuzzy`
Calculated try_task_config.json:
{
"tasks": [

"test-android-hw-g5-7-0-arm7-api-16/opt-raptor-speedometer-geckoview-e10s",

"test-android-hw-g5-7-0-arm7-api-16/opt-raptor-speedometer-geckoview-power-e10s",

"test-android-hw-g5-7-0-arm7-api-16/opt-raptor-unity-webgl-geckoview-e10s",
"test-android-hw-p2-8-0-android-aarch64/opt-jittest-1",
"test-android-hw-p2-8-0-android-aarch64/opt-jittest-10",
"test-android-hw-p2-8-0-android-aarch64/opt-jittest-2",
"test-android-hw-p2-8-0-android-aarch64/opt-jittest-3",
"test-android-hw-p2-8-0-android-aarch64/opt-jittest-4",
"test-android-hw-p2-8-0-android-aarch64/opt-jittest-5",
"test-android-hw-p2-8-0-android-aarch64/opt-jittest-6",
"test-android-hw-p2-8-0-android-aarch64/opt-jittest-7",
"test-android-hw-p2-8-0-android-aarch64/opt-jittest-8",
"test-android-hw-p2-8-0-android-aarch64/opt-jittest-9",

"test-android-hw-p2-8-0-android-aarch64/opt-raptor-speedometer-geckoview-e10s",

"test-android-hw-p2-8-0-android-aarch64/opt-raptor-speedometer-geckoview-power-e10s",
"test-android-hw-p2-8-0-arm7-api-16/debug-mochitest-media-1",
"test-android-hw-p2-8-0-arm7-api-16/debug-mochitest-media-2",
"test-android-hw-p2-8-0-arm7-api-16/debug-mochitest-media-3",
"test-android-hw-p2-8-0-arm7-api-16/opt-jittest-1",
"test-android-hw-p2-8-0-arm7-api-16/opt-jittest-10",
"test-android-hw-p2-8-0-arm7-api-16/opt-jittest-2",
"test-android-hw-p2-8-0-arm7-api-16/opt-jittest-3",
"test-android-hw-p2-8-0-arm7-api-16/opt-jittest-4",
"test-android-hw-p2-8-0-arm7-api-16/opt-jittest-5",
"test-android-hw-p2-8-0-arm7-api-16/opt-jittest-6",
"test-android-hw-p2-8-0-arm7-api-16/opt-jittest-7",
"test-android-hw-p2-8-0-arm7-api-16/opt-jittest-8",
"test-android-hw-p2-8-0-arm7-api-16/opt-jittest-9",
"test-android-hw-p2-8-0-arm7-api-16/opt-mochitest-media-1",
"test-android-hw-p2-8-0-arm7-api-16/opt-mochitest-media-2",
"test-android-hw-p2-8-0-arm7-api-16/opt-mochitest-media-3",

"test-android-hw-p2-8-0-arm7-api-16/opt-raptor-speedometer-geckoview-e10s",

"test-android-hw-p2-8-0-arm7-api-16/opt-raptor-speedometer-geckoview-power-e10s",

"test-android-hw-p2-8-0-arm7-api-16/opt-raptor-unity-webgl-geckoview-e10s"
],
"templates": {
"env": {
"TRY_SELECTOR": "fuzzy"
}
},
"version": 1
}

/bc
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Please upgrade to at least Mercurial 2.5.1

[Bob Clary]

On 02/21/2013 03:36 AM, Gervase Markham wrote:


The Mercurial download page:
http://mercurial.selenic.com/downloads/
offers 2.5.1 for Mac and Windows, but no Linux packages. Can guidance be
provided as to where to get such things for commonly-run versions of Linux?


On Fedora 18 I just yum erased mercurial, downloaded the tarball and 
after extracting it did a sudo make install. That placed it in 
/usr/local which is easy enough to clean out if needed in the future.



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform