845886 - Make opt + assertions (aka release + debug) the default B2G developer build

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: GonkIntegration, defect, P3)

Description

[Justin Lebar (not reading bugmail)]

There was some discussion on the mailing list asking developers to test with debug builds, since our default release builds don't have assertions enabled.

I think the goal here is laudable, but I also think it's unrealistic to expect the proposed solution to become widely adopted.  Many people are going to continue using the default build config because it's easy.  And anyway, builds take time, and it's asking a lot for me to do a separate build just to play around with it and maybe catch an assertion.

So would anyone object if we changed our default developer builds to opt + assertions (which I think in Gecko goes by the name release + debug)?  I'd want to know two things before we flipped this switch:

1) How slow are such builds?  I'd expect them to be reasonably fast.  If they're too slow maybe we can figure out why.

2) How stable are such builds?  I'd expect we'd need to put in some time to fix assertions we're likely hitting.  But of course that work would be productive.

Ben, when you tested debug builds for your newsgroup post, were you testing opt + assert builds, or no-opt + assert builds?

Comment 1

[Ben Turner (not reading bugmail, use the needinfo flag!)]

I was doing no-opt+debug. Switching to opt+debug sounds great to me though!

Comment 2

[Mike Habicher [:mikeh] (high bugzilla latency)]

1. I do opt+debug builds almost all the time, and they're noticeably slower than non-debug builds when running on Unagi.  <handwave>I'd guess maybe half the speed of non-debug builds.</handwave>  Slow enough that when I occasionally make a non-debug build, I'm amazed at how fast it is.

2. The builds are stable, provided you don't get caught having to track down a fatal assertion that someone inserted but never tested/caught.  At least once, after fixing one assertion, I started hitting another one.

Comment 3

[Mike Habicher [:mikeh] (high bugzilla latency)]

(I also support switching to opt+debug.)

Comment 4

[Justin Lebar (not reading bugmail)]

> 1. I do opt+debug builds almost all the time, and they're noticeably slower than non-debug builds 
> when running on Unagi. 

Okay; it sounds like we should profile some to understand why this is happening.  Hopefully it's just a few expensive |ifdef DEBUG| things that we can turn off.

Comment 5

[Benoit Jacob [:bjacob] (mostly away)]

Here is a B2G try push with a configure.in change that should enable DEBUG unconditionally:
https://tbpl.mozilla.org/?tree=Try&rev=ca965e23ff82

Comment 6

[Benoit Jacob [:bjacob] (mostly away)]

Argh, no tests... trying with 'emulator' added.
https://tbpl.mozilla.org/?tree=Try&rev=4ae2e931ccf4

Comment 7

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

I think it's important that this happen, if we intend to take b2g seriously as an operating system and as a software project in general, but I can't commit the time needed to work on it.

Comment 8

[Dave Huseby [:huseby]]

This bug is independent of our other perf work.  Since I think it is lower priority, I'm throwing it into the first sprint after all of our other work.

Comment 9

[Dave Huseby [:huseby]]

I think parts of this have already been accomplished.  I'm not sure making the switch in this way is a priority anymore.

Comment 10

[Gregor Wagner [:gwagner]]

(In reply to Dave Huseby [:huseby] from comment #9)
> I think parts of this have already been accomplished.  I'm not sure making
> the switch in this way is a priority anymore.

Where did this happen? I am seeing more and more assertions triggering with debug builds so I am not sure we should close this bug. We are currently working on sorting out the assertions that are too slow for debug builds with JS engineers.

Comment 11

[BMO Automation]

Firefox OS is not being worked on