1490988 - Crash in <alloc::vec::Vec<T> as core::clone::Clone>::clone

Status: RESOLVED WORKSFORME

(Core :: CSS Parsing and Computation, defect, P1)

Description

[Calixte Denizet (:calixte)]

This bug was filed from the Socorro interface and is
report bp-ee828121-94f7-4b0d-9cb8-13e810180913.
=============================================================

Top 10 frames of crashing thread:

0 libxul.so <alloc::vec::Vec<T> as core::clone::Clone>::clone src/liballoc/vec.rs:1880
1 libxul.so <style::properties::PropertyDeclaration as core::clone::Clone>::clone servo/components/style/values/generics/transform.rs:293
2 libxul.so Servo_StyleSet_GetKeyframesForName toolkit/library/armv7-linux-androideabi/release/build/style-90ab97c350cba8c9/out/properties.rs:48508
3 libxul.so Gecko_UpdateAnimations layout/style/ServoStyleSet.cpp:1169
4 libxul.so core::ptr::drop_in_place servo/components/style/gecko/wrapper.rs:1541
5 libxul.so geckoservo::glue::traverse_subtree servo/components/style/driver.rs:182
6 libxul.so Servo_TraverseSubtree servo/ports/geckolib/glue.rs:352
7 libxul.so mozilla::ServoStyleSet::StyleNewSubtree layout/style/ServoStyleSet.cpp:1061
8 libxul.so nsCSSFrameConstructor::CreateGeneratedContentItem layout/base/nsCSSFrameConstructor.cpp:1868
9 libxul.so nsCSSFrameConstructor::ProcessChildren layout/base/nsCSSFrameConstructor.cpp:10104

=============================================================

There are 7 crashes (7 installs) in nightly 64 starting with buildid 20180912100128.
The pushlog for this build is:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=423bdf7a802b&tochange=703546ab6d0c

:emilio, could you investigate please ?

Comment 1

[Andrew McCreight [:mccr8]]

This is the top crash for Android Nightly builds for Sept 12, with 10 crashes.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Huh, I thought I commented here... I don't see anything suspicious on the pushlog, which is unfortunate.

Also, this is not only related to animations, since there are other callers that also crash here, so there goes my hope of redirecting this crash to Hiro or Brian... ;)

PropertyDeclaration::clone is a bit nasty to save codesize, but I don't see anything suspicious there (or anything that should be android-specific, really). Also a SIGILL looks really weird / bad.

Ted, do you know if we've changed recently something specific to how how we build Rust code on Android / ARM?

If not... Are there docs to investigate android crashes so I can look into which instruction we crash and what source line does it correspond to? (Would be first doing this).

Comment 3

[Sean Voisen (:svoisen)]

Going to set to P1 for now given it's a top crash on Android Nightly (though we don't have much longer-term data yet).

Comment 4

[(not currently active) Ted Mielczarek]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)
> Huh, I thought I commented here... I don't see anything suspicious on the
> pushlog, which is unfortunate.
> 
> Also, this is not only related to animations, since there are other callers
> that also crash here, so there goes my hope of redirecting this crash to
> Hiro or Brian... ;)
> 
> PropertyDeclaration::clone is a bit nasty to save codesize, but I don't see
> anything suspicious there (or anything that should be android-specific,
> really). Also a SIGILL looks really weird / bad.

`SIGILL` can be a panic, I know on x86 the LLVM abort intrinsic compiles down to a `ud2` instruction. I don't know about arm though.

> Ted, do you know if we've changed recently something specific to how how we
> build Rust code on Android / ARM?

Nothing that I know of immediately, but CCing a few other folks.

> If not... Are there docs to investigate android crashes so I can look into
> which instruction we crash and what source line does it correspond to?
> (Would be first doing this).

I don't think we have docs on this specifically, but if you have access to download the minidump you can use my `get-minidump-instructions` tool from this crate to disassemble the crashing instructions and get source-interleaved assembly:
https://github.com/luser/rust-minidump/tree/master/minidump-tools (sorry, I haven't published minidump-tools to crates.io yet!)

Comment 5

[(not currently active) Ted Mielczarek]

This can be a bit of a pain and my Rust tools can't read this minidump at the moment so I used my C++ tool. Hopefully the disassembly here makes sense, I'm not conversant in arm assembly:

Disassembly of section .data:

cb1b8f7e <.data>:
http://github.com/rust-lang/rust/blob/9634041f0e8c0f3191d2867311276f19d0a42564/src/liballoc/vec.rs#L1880
 1880                 for element in iterator {
cb1b8f7e:	f88d 00b6 	strb.w	r0, [sp, #182]	; 0xb6
http://github.com/rust-lang/rust/blob/9634041f0e8c0f3191d2867311276f19d0a42564/src/libcore/ptr.rs#L363
  363     intrinsics::move_val_init(&mut *dst, src)
cb1b8f82:	982a      	ldr	r0, [sp, #168]	; 0xa8
http://github.com/rust-lang/rust/blob/9634041f0e8c0f3191d2867311276f19d0a42564/src/liballoc/vec.rs#L1880
 1880                 for element in iterator {
cb1b8f84:	f88d a0ce 	strb.w	r10, [sp, #206]	; 0xce
cb1b8f88:	f8ad 30c0 	strh.w	r3, [sp, #192]	; 0xc0
cb1b8f8c:	f88d 60c2 	strb.w	r6, [sp, #194]	; 0xc2
cb1b8f90:	f8ad 50bc 	strh.w	r5, [sp, #188]	; 0xbc
cb1b8f94:	f88d 70be 	strb.w	r7, [sp, #190]	; 0xbe
cb1b8f98:	f8ad 20b8 	strh.w	r2, [sp, #184]	; 0xb8
http://github.com/rust-lang/rust/blob/9634041f0e8c0f3191d2867311276f19d0a42564/src/libcore/ptr.rs#L363
  363     intrinsics::move_val_init(&mut *dst, src)
cb1b8f9c:	eb0b 0209 	add.w	r2, r11, r9
http://github.com/rust-lang/rust/blob/9634041f0e8c0f3191d2867311276f19d0a42564/src/liballoc/vec.rs#L1880
 1880                 for element in iterator {
cb1b8fa0:	f88d 40ba 	strb.w	r4, [sp, #186]	; 0xba
cb1b8fa4:	f88d c0d2 	strb.w	r12, [sp, #210]	; 0xd2
http://github.com/rust-lang/rust/blob/9634041f0e8c0f3191d2867311276f19d0a42564/src/libcore/ptr.rs#L363
  363     intrinsics::move_val_init(&mut *dst, src)
cb1b8fa8:	f84b 0009 	str.w	r0, [r11, r9]
http://github.com/rust-lang/rust/blob/9634041f0e8c0f3191d2867311276f19d0a42564/src/liballoc/vec.rs#L1880
 1880                 for element in iterator {
cb1b8fac:	fa5f f08e 	uxtb.w	r0, lr
cb1b8fb0:	ea40 2001 	orr.w	r0, r0, r1, lsl #8
http://github.com/rust-lang/rust/blob/9634041f0e8c0f3191d2867311276f19d0a42564/src/libcore/ptr.rs#L363
  363     intrinsics::move_val_init(&mut *dst, src)
cb1b8fb4:	6190      	str	r0, [r2, #24]
http://github.com/rust-lang/rust/blob/9634041f0e8c0f3191d2867311276f19d0a42564/src/libcore/slice/mod.rs#L2390
 2390                     if self.ptr == self.end {
cb1b8fb6:	f109 0984 	add.w	r9, r9, #132	; 0x84
http://github.com/rust-lang/rust/blob/9634041f0e8c0f3191d2867311276f19d0a42564/src/libcore/ptr.rs#L363
  363     intrinsics::move_val_init(&mut *dst, src)
cb1b8fba:	9824      	ldr	r0, [sp, #144]	; 0x90
cb1b8fbc:	6150      	str	r0, [r2, #20]
http://github.com/rust-lang/rust/blob/9634041f0e8c0f3191d2867311276f19d0a42564/src/liballoc/vec.rs#L1880
 1880                 for element in iterator {
cb1b8fbe:	9822      	ldr	r0, [sp, #136]	; 0x88
cb1b8fc0:	991e      	ldr	r1, [sp, #120]	; 0x78
cb1b8fc2:	9b26      	ldr	r3, [sp, #152]	; 0x98
cb1b8fc4:	b2c0      	uxtb	r0, r0
cb1b8fc6:	9e25      	ldr	r6, [sp, #148]	; 0x94
cb1b8fc8:	ea40 2001 	orr.w	r0, r0, r1, lsl #8
http://github.com/rust-lang/rust/blob/9634041f0e8c0f3191d2867311276f19d0a42564/src/libcore/ptr.rs#L363
  363     intrinsics::move_val_init(&mut *dst, src)
cb1b8fcc:	6210      	str	r0, [r2, #32]
cb1b8fce:	9823      	ldr	r0, [sp, #140]	; 0x8c
cb1b8fd0:	61d0      	str	r0, [r2, #28]
cb1b8fd2:	46b4      	mov	r12, r6
http://github.com/rust-lang/rust/blob/9634041f0e8c0f3191d2867311276f19d0a42564/src/liballoc/vec.rs#L1880
 1880                 for element in iterator {
cb1b8fd4:	981f      	ldr	r0, [sp, #124]	; 0x7c
cb1b8fd6:	9908      	ldr	r1, [sp, #32]
cb1b8fd8:	9c27      	ldr	r4, [sp, #156]	; 0x9c
cb1b8fda:	b2c0      	uxtb	r0, r0
cb1b8fdc:	f8dd a0b0 	ldr.w	r10, [sp, #176]	; 0xb0
cb1b8fe0:	ea40 2001 	orr.w	r0, r0, r1, lsl #8
http://github.com/rust-lang/rust/blob/9634041f0e8c0f3191d2867311276f19d0a42564/src/libcore/ptr.rs#L363
  363     intrinsics::move_val_init(&mut *dst, src)
cb1b8fe4:	6310      	str	r0, [r2, #48]	; 0x30
cb1b8fe6:	981d      	ldr	r0, [sp, #116]	; 0x74
cb1b8fe8:	62d0      	str	r0, [r2, #44]	; 0x2c
cb1b8fea:	9828      	ldr	r0, [sp, #160]	; 0xa0
cb1b8fec:	6050      	str	r0, [r2, #4]
http://github.com/rust-lang/rust/blob/9634041f0e8c0f3191d2867311276f19d0a42564/src/liballoc/vec.rs#L1880
 1880                 for element in iterator {
cb1b8fee:	9829      	ldr	r0, [sp, #164]	; 0xa4
cb1b8ff0:	9f2b      	ldr	r7, [sp, #172]	; 0xac
cb1b8ff2:	9d07      	ldr	r5, [sp, #28]
 1880                 for element in iterator {
cb1b8ff4:	b2c0      	uxtb	r0, r0
 1507         self.local_len += increment;
cb1b8ff6:	3701      	adds	r7, #1
 1880                 for element in iterator {
cb1b8ff8:	ea40 2003 	orr.w	r0, r0, r3, lsl #8
http://github.com/rust-lang/rust/blob/9634041f0e8c0f3191d2867311276f19d0a42564/src/libcore/ptr.rs#L363
  363     intrinsics::move_val_init(&mut *dst, src)
cb1b8ffc:	6090      	str	r0, [r2, #8]
http://github.com/rust-lang/rust/blob/9634041f0e8c0f3191d2867311276f19d0a42564/src/liballoc/vec.rs#L1880
 1880                 for element in iterator {
cb1b8ffe:	fa5f f088 	uxtb.w	r0, r8
^^^^^^^^^	^^^^^^^^^^	^^^^^^	^^^^^^^
http://github.com/rust-lang/rust/blob/9634041f0e8c0f3191d2867311276f19d0a42564/src/libcore/ptr.rs#L363
  363     intrinsics::move_val_init(&mut *dst, src)
cb1b9002:	60d4      	str	r4, [r2, #12]
http://github.com/rust-lang/rust/blob/9634041f0e8c0f3191d2867311276f19d0a42564/src/liballoc/vec.rs#L1880
 1880                 for element in iterator {
cb1b9004:	ea40 2006 	orr.w	r0, r0, r6, lsl #8
http://github.com/rust-lang/rust/blob/9634041f0e8c0f3191d2867311276f19d0a42564/src/libcore/ptr.rs#L363

Comment 6

[Mike Hommey [:glandium]]

(In reply to Ted Mielczarek [:ted] [:ted.mielczarek] from comment #5)
> This can be a bit of a pain and my Rust tools can't read this minidump at
> the moment so I used my C++ tool. Hopefully the disassembly here makes
> sense, I'm not conversant in arm assembly:
> 
> Disassembly of section .data:

Section .data?!?

Comment 7

[Mike Hommey [:glandium]]

(In reply to Mike Hommey [:glandium] from comment #6)
> (In reply to Ted Mielczarek [:ted] [:ted.mielczarek] from comment #5)
> > This can be a bit of a pain and my Rust tools can't read this minidump at
> > the moment so I used my C++ tool. Hopefully the disassembly here makes
> > sense, I'm not conversant in arm assembly:
> > 
> > Disassembly of section .data:
> 
> Section .data?!?

That's just the tool doing something weird. The assembly *does* correspond to the right thing, but the section it's been attributed to is wrong. The actual section is .text, which is more normal.

uxbt.w is a zero-extend instruction, and according to the ARM assembler reference manual, it's supported in ARMv6T2 and above. It shouldn't be an illegal instruction.

Comment 8

[(not currently active) Ted Mielczarek]

Yeah, the C++ version of the tool just writes the instructions from the minidump out to a file and shells out to objdump, so the output is a little weird.

Comment 9

[Marcia Knous [:marcia]]

It looks as if this was a one day spike on the 12th - I don't see any crashes since then.

Comment 10

[Jason Duell]

Let's see what happens in the next week--we may close this if crashes keep not happening