mirror of
https://gitlab.winehq.org/wine/wine-gecko.git
synced 2024-09-13 09:24:08 -07:00
Gecko engine for Wine
6367a9c217
This allows most of the tests to run without the -d command-line flag. Now a compartment is in debug mode if * JSD1 wants debug mode on, thanks to a JS_SetDebugMode* call; OR * JSD2 wants debug mode on, because a live Debug object has a debuggee global in that compartment. Since this patch only adds the second half of the rule, JSD1 should be unaffected. The new rule has three issues: 1. When removeDebuggee is called, it can cause debug mode to be turned off for a compartment. If any scripts from that compartment are on the stack, and the methodjit is enabled, returning to those stack frames will crash. 2. When a Debug object is GC'd, it can cause debug mode to be turned off for one or more compartments. This causes the same problem with returning to deleted methodjit code, but the fix is different: such Debug objects simply should not be GC'd. 3. Setting .enabled to false still does not turn off debug mode anywhere, so it does not reduce overhead as much as it should. A possible fix for issue #1 would be to make such removeDebuggee calls throw; a different possibility is to turn off debug mode but leave all the scripts alone, accepting the performance loss (as we do for JSD1 in JSCompartment::setDebugModeFromC). The fix to issues #2 and #3 is to tweak the rule--and to tweak the rule for Debug object GC-reachability. --HG-- rename : js/src/jit-test/tests/debug/Debug-ctor.js => js/src/jit-test/tests/debug/Debug-ctor-01.js |
||
|---|---|---|
| accessible | ||
| browser | ||
| build | ||
| caps | ||
| chrome | ||
| config | ||
| content | ||
| db | ||
| dbm | ||
| docshell | ||
| dom | ||
| editor | ||
| embedding | ||
| extensions | ||
| gfx | ||
| intl | ||
| ipc | ||
| jpeg | ||
| js | ||
| layout | ||
| media | ||
| memory | ||
| mfbt | ||
| mobile | ||
| modules | ||
| netwerk | ||
| nsprpub | ||
| other-licenses | ||
| parser | ||
| probes | ||
| profile | ||
| rdf | ||
| security | ||
| services | ||
| startupcache | ||
| storage | ||
| testing | ||
| toolkit | ||
| tools | ||
| uriloader | ||
| view | ||
| widget | ||
| xpcom | ||
| xpfe | ||
| xpinstall | ||
| xulrunner | ||
| .hgignore | ||
| .hgtags | ||
| aclocal.m4 | ||
| allmakefiles.sh | ||
| client.mk | ||
| client.py | ||
| configure.in | ||
| LEGAL | ||
| LICENSE | ||
| Makefile.in | ||
| README.txt | ||
An explanation of the Mozilla Source Code Directory Structure and links to
project pages with documentation can be found at:
https://developer.mozilla.org/en/Mozilla_Source_Code_Directory_Structure
For information on how to build Mozilla from the source code, see:
http://developer.mozilla.org/en/docs/Build_Documentation
To have your bug fix / feature added to Mozilla, you should create a patch and
submit it to Bugzilla (https://bugzilla.mozilla.org). Instructions are at:
http://developer.mozilla.org/en/docs/Creating_a_patch
http://developer.mozilla.org/en/docs/Getting_your_patch_in_the_tree
If you have a question about developing Mozilla, and can't find the solution
on http://developer.mozilla.org, you can try asking your question in a
mozilla.* Usenet group, or on IRC at irc.mozilla.org. [The Mozilla news groups
are accessible on Google Groups, or news.mozilla.org with a NNTP reader.]
You can download nightly development builds from the Mozilla FTP server.
Keep in mind that nightly builds, which are used by Mozilla developers for
testing, may be buggy. Firefox nightlies, for example, can be found at:
ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/
- or -
http://nightly.mozilla.org/