Re: FF 60.1ESR Crash on s390x

[Steve Fink]

On 08/31/2018 04:33 PM, Charles G Robertson wrote:

Hi,

I'm hoping someone can shed some light on this. I am trying to build Firefox 
60.1ESR for s390x. When I install and run it crashes (segfault, core dump). See 
the stack trace below.
It is crashing on this statement incrementing a member of this "zone" object. 
Should I enter a bug on this?


Yes, file a bug on product=Core, component=JavaScript Engine, and CC me 
(:sfink, or sph...@gmail.com). It will be easier to discuss there. But 
what I'll first ask is:


Are you intentionally running with nursery strings (bug 903519) enabled? 
Because it thinks you are, though that might be because things are 
getting corrupted so a "never happens" bit pattern is happening. But 
just in case you *are* running with nursery strings enabled, don't. 
There are known bugs in that version. (It defaults to off, but you can 
enable them with an environment variable or a preference.)


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

FF 60.1ESR Crash on s390x

[Charles G Robertson]

Hi,

I'm hoping someone can shed some light on this. I am trying to build Firefox 
60.1ESR for s390x. When I install and run it crashes (segfault, core dump). See 
the stack trace below.
It is crashing on this statement incrementing a member of this "zone" object. 
Should I enter a bug on this?

Thanks
Cheers
  Charles Robertson

Thread 1 "firefox" received signal SIGSEGV, Segmentation fault.
js::TenuringTracer::moveToTenured (this=0x3ff19f8, src=0x3ffad358ad8) at 
/usr/src/debug/mozilla/js/src/gc/Marking.cpp:3226
3226zone->tenuredStrings++;
(gdb) bt
#0  js::TenuringTracer::moveToTenured (this=0x3ff19f8, src=0x3ffad358ad8) 
at /usr/src/debug/mozilla/js/src/gc/Marking.cpp:3226
#1  0x03fff7b8d950 in js::TenuringTracer::traverse 
(this=, strp=0x2aa0062eb70) at 
/usr/src/debug/mozilla/js/src/gc/Marking.cpp:2743
#2  0x03fff7b8e2e0 in 
js::gc::StoreBuffer::MonoTypeBuffer::trace 
(this=this@entry=0x2aa00194030, owner=owner@entry=0x2aa00194010, mover=...)
at /usr/src/debug/mozilla/js/src/gc/Marking.cpp:2770
#3  0x03fff7b9b7cc in js::gc::StoreBuffer::traceCells (mover=..., 
this=0x2aa00194010) at /usr/src/debug/mozilla/js/src/gc/StoreBuffer.h:440
#4  js::Nursery::doCollection (this=0x3ffad3fced8, this@entry=0x2aa00193ce8, 
reason=reason@entry=JS::gcreason::API, tenureCounts=...) at 
/usr/src/debug/mozilla/js/src/gc/Nursery.cpp:858
#5  0x03fff7b9c250 in js::Nursery::collect (this=this@entry=0x2aa00193ce8, 
reason=) at /usr/src/debug/mozilla/js/src/gc/Nursery.cpp:724
#6  0x03fff7b621ce in js::gc::GCRuntime::minorGC (this=0x2aa00191b98, 
reason=reason@entry=JS::gcreason::OUT_OF_NURSERY, 
phase=phase@entry=js::gcstats::PhaseKind::MINOR_GC)
at /usr/src/debug/mozilla/js/src/gc/GC.cpp:7749
#7  0x03fff7b8 in js::gc::GCRuntime::minorGC 
(phase=js::gcstats::PhaseKind::MINOR_GC, reason=JS::gcreason::OUT_OF_NURSERY, 
this=) at /usr/src/debug/mozilla/js/src/gc/Allocator.cpp:47
#8  js::gc::GCRuntime::tryNewNurseryObject<(js::AllowGC)1> (this=, clasp=0x3fff940d7c0 , nDynamicSlots=0, thingSize=64, 
cx=0x2aa00196320)
at /usr/src/debug/mozilla/js/src/gc/Allocator.cpp:94
#9  js::Allocate (cx=0x2aa00196320, kind=, nDynamicSlots=0, heap=, clasp=0x3fff940d7c0 
)
at /usr/src/debug/mozilla/js/src/gc/Allocator.cpp:56
#10 0x03fff79f46cc in js::NativeObject::create (group=..., shape=..., 
heap=, kind=js::gc::AllocKind::FUNCTION, cx=0x2aa00338570) at 
/usr/src/debug/mozilla/js/src/vm/NativeObject-inl.h:538
#11 NewObject (cx=0x2aa00338570, cx@entry=0x3ffad27ba00, group=..., 
group@entry=..., kind=kind@entry=js::gc::AllocKind::FUNCTION, 
newKind=newKind@entry=js::GenericObject, 
initialShapeFlags=initialShapeFlags@entry=0) at 
/usr/src/debug/mozilla/js/src/vm/JSObject.cpp:729
#12 0x03fff79f73f6 in js::NewObjectWithClassProtoCommon (cx=0x3ffad27ba00, 
cx@entry=0x2aa00196320, clasp=clasp@entry=0x3fff940d7c0 , 
protoArg=..., protoArg@entry=..., 
allocKind=allocKind@entry=js::gc::AllocKind::FUNCTION, newKind=) at /usr/src/debug/mozilla/js/src/vm/JSObject.cpp:850
#13 0x03fff79b132a in js::NewObjectWithClassProto 
(newKind=js::GenericObject, allocKind=js::gc::AllocKind::FUNCTION, proto=..., 
clasp=0x3fff940d7c0 , cx=0x2aa00196320)
at /usr/src/debug/mozilla/js/src/vm/JSObject-inl.h:677
#14 NewFunctionClone (cx=cx@entry=0x2aa00196320, fun=..., fun@entry=..., 
newKind=, allocKind=, proto=..., proto@entry=...) 
at /usr/src/debug/mozilla/js/src/vm/JSFunction.cpp:2052
#15 0x03fff79b4d04 in js::CloneFunctionReuseScript (cx=0x2aa00196320, 
cx@entry=0x178, fun=fun@entry=..., enclosingEnv=enclosingEnv@entry=..., 
allocKind=allocKind@entry=js::gc::AllocKind::FUNCTION, 
newKind=, proto=...) at 
/usr/src/debug/mozilla/js/src/vm/JSFunction.cpp:2092
#16 0x03fff7753c40 in js::CloneFunctionObjectIfNotSingleton (cx=0x178, 
fun=..., parent=..., proto=proto@entry=..., 
newKind=newKind@entry=js::GenericObject)
at /usr/src/debug/mozilla/js/src/vm/JSFunction-inl.h:89
#17 0x03fff77542c0 in js::Lambda (cx=, fun=..., parent=...) 
at /usr/src/debug/mozilla/js/src/vm/Interpreter.cpp:4439
#18 0x03fff7759862 in Interpret (cx=0x2aa00196320, state=...) at 
/usr/src/debug/mozilla/js/src/vm/Interpreter.cpp:3637
#19 0x03fff7760e34 in js::RunScript (cx=, state=...) at 
/usr/src/debug/mozilla/js/src/vm/Interpreter.cpp:418
#20 0x03fff77612b0 in js::InternalCallOrConstruct (cx=0x2aa00196320, 
args=..., construct=) at 
/usr/src/debug/mozilla/js/src/vm/Interpreter.cpp:490
#21 0x03fff7754bc6 in js::CallFromStack (args=..., cx=) at 
/usr/src/debug/mozilla/js/src/vm/Interpreter.cpp:523
#22 Interpret (cx=0x2aa00196320, state=...) at 
/usr/src/debug/mozilla/js/src/vm/Interpreter.cpp:3115
#23 0x03fff7760e34 in js::RunScript (cx=, state=...) at 
/usr/src/debug/mozilla/js/src/vm/Interpreter.cpp:418
#24 0x03fff77612b0 in js::InternalCallOrConstruct (cx=0x2aa00196320, 
args=..., construct=) at 
/usr/src/debug/mozilla/js/src/vm/Interpreter.cpp:490
#25 0x03fff7754bc6 in js

Re: Intent to remove DHE ciphers from WebRTC DTLS handshake

[Nicholas Alexander]

On Thu, Aug 30, 2018 at 2:15 PM, Nicholas Alexander 
wrote:

>
>
> On Wed, Aug 29, 2018 at 3:56 PM, Nils Ohlmeier 
> wrote:
>
>> Summary:
>>
>> We are looking at removing the DHE cipher suites from the DTLS handshake
>> in Firefox soon.
>>
>> Ciphers:
>> - TLS_DHE_RSA_WITH_AES_128_CBC_SHA
>> - TLS_DHE_RSA_WITH_AES_256_CBC_SHA
>> are the  two suites which we want to remove, because they are considered
>> too weak.
>>
>
> Are these suites considered "too weak" across the board?  For historical
> reasons Firefox for Android will handshake to Firefox Sync servers using
> these suites: https://searchfox.org/mozilla-central/rev/
> 05d91d3e02a0780f44599371005591d7988e2809/mobile/android/
> services/src/main/java/org/mozilla/gecko/background/
> common/GlobalConstants.java#73.  Sounds like we should drop those suites
> there too -- can you confirm?
>

After a little (off-list) discussion, I've filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1487842 tracking dropping
these.

Thanks, Nils (and others)!
Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rebuild speeds (Was: Re: JS compilation/evaluation APIs are now in #include "js/CompilationAndEvaluation.h")

[Ted Mielczarek]

On Thu, Aug 30, 2018, at 6:28 PM, Michael Shal wrote:
> On Thu, Aug 30, 2018 at 6:04 PM, Michael Shal  wrote:
> >
> >
> > In this case, the 99:44 rebuild times look to be an artifact of how the
> > outputs of GenerateServoStyleConsts.py are consumed by a large chunk of the
> > Rust and C++ code. Attached is a graphviz .dot file for reference (with
> > graphviz, 'dot -Tpng servo-style-consts.dot > servo-style-consts.png' and
> > view the image).
> >
> 
> I'm told the attachment was eaten. Here it is inline:

For the lazy folks among us (like me, normally), I've uploaded the graphviz 
output here: https://i.imgur.com/etqkwgV.png

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

Re: Extending the length of an XPCOM string when writing to it via a raw pointer

[Henri Sivonen]

On Fri, Aug 31, 2018 at 8:43 AM, Henri Sivonen  wrote:
> At this point, it's probably relevant to mention that SetCapacity() in
> situations other that ahead of a sequence of Append()s is most likely
> wrong (and has been so since at least 2004; I didn't bother doing code
> archeology further back than that).

I wrote some SetCapacity() docs at:
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Guide/Internal_strings#Sequence_of_appends_without_reallocating

(I caused SetLength, AppendUTF16toUTF8 and AppendUTF8toUTF16 to move
from the first list to the second, but, other than that, XPCOM strings
have been this way long before I took a look at this code and I'm just
the messenger here.)

Also filed a static analysis request for this:
https://bugzilla.mozilla.org/show_bug.cgi?id=1487612

-- 
Henri Sivonen
hsivo...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform