Closed
Bug 907914
Opened 11 years ago
Closed 11 years ago
Turn on thread safety assertions in opt builds on trunk.
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
FIXED
mozilla26
People
(Reporter: khuey, Assigned: khuey)
References
Details
Attachments
(1 file)
(deleted),
patch
|
bent.mozilla
:
review+
|
Details | Diff | Splinter Review |
No description provided.
Assignee | ||
Comment 1•11 years ago
|
||
Attachment #793677 -
Flags: review?(bent.mozilla)
Comment 2•11 years ago
|
||
\o/
Comment on attachment 793677 [details] [diff] [review]
Patch
Review of attachment 793677 [details] [diff] [review]:
-----------------------------------------------------------------
Looks good to me! I just hope we run this on b2g...
Attachment #793677 -
Flags: review?(bent.mozilla) → review+
Assignee | ||
Comment 4•11 years ago
|
||
Flags: in-testsuite+
Comment 5•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
Comment 6•11 years ago
|
||
This ruins all the profiling on Nightlies.
I was profiling a testcase and wondered why AddRef/Release have suddenly become slower again
and why they end up calling PR_GetCurrentThread().
(The patch tripled the number of instructions in cycle collectable AddRef )
Assignee | ||
Comment 7•11 years ago
|
||
Mmm, yes, I could see why that would be a problem.
Assignee | ||
Comment 8•11 years ago
|
||
Maybe we can gate this on --enable-profiling.
Comment 9•11 years ago
|
||
Gating on --enable-profiling will work, but profiling a non-enable-profiling build (obviously) would be affected, like a true nightly (I assume they're built without --enable-profiling?) Olli, were you profiling local builds or true nightlies? Also, we might want to make it easier to generate --enable-profiling Try builds for similar reasons (and also publish the symbols needed if that's on).
If that's the primary issue (profiling), I'd be tempted to gate it. As we use more complex threading, the chances of this sort of thing biting us increases. (WebRTC, WebAudio, B2G, etc). We purposely have left some thread-safety checks in WebRTC (and may re-enable others) for this reason, especially in non-perf-critical paths.
Flags: needinfo?(bugs)
Comment 10•11 years ago
|
||
I profile both. And Nightlies have --enable-profiling.
Note, for desktop development people do use debug builds and we get the
thread safety assertions in such builds.
Flags: needinfo?(bugs)
Comment 11•11 years ago
|
||
(In reply to comment #10)
> I profile both. And Nightlies have --enable-profiling.
Why is profiling a build without --enable-profiling useful for you?
Comment 12•11 years ago
|
||
Why wouldn't it be? I may explicitly enable stuff like -fno-omit-frame-pointer.
And anyhow the point was that I profile my own builds and Nightlies, and Nightlies have
-enable-profiling set. (my own builds may or may not have that.)
Comment 13•11 years ago
|
||
(In reply to comment #12)
> Why wouldn't it be? I may explicitly enable stuff like -fno-omit-frame-pointer.
> And anyhow the point was that I profile my own builds and Nightlies, and
> Nightlies have
> -enable-profiling set. (my own builds may or may not have that.)
Oh, well, the reason I asked is that -enable-profiling basically does -fno-omit-frame-pointer, but if you do that yourself then that's fine!
You need to log in
before you can comment on or make changes to this bug.
Description
•