Bug 581341 is adding a pragma that turns off optimization for the new EscapeAnnotation function in nsExceptionHandler.cpp, as doing a PGO build without it reliably produces a build that crashes in SVG painting code. Note that this occurs in the build that is to be profiled; we never reach the stage of having an optimized build. Jeff and I tracked it down to a function where eax was not being filled with the proper return value, and instead held a pointer to the code segment, so the caller had the wrong value returned. This occurred in both 2005 and 2008; I'm hoping it's fixed by 2010.
I do PGO builds with MSVC 2010, but with the Crash Reporter disabled (for obvious reasons). I can try one with it enabled to see what happens if you like.
That would be super. I'll put together a patch when bug 581341 lands.
It's all yours, Ryan.
I guess this is a bad sign? c:\mozbuild\mozilla-central\client.mk:214:0$ OBJDIR=c:/mozbuild/mozilla-central/objdir-fx JARLOG_DIR=c:/mozbuild/mozilla-central/objdir-fx/jarlog/en-US python c:/mozbuild/mozilla-central/objdir-fx/_profile/pgo/profileserver.py args: ['c:\\mozbuild\\mozilla-central\\objdir-fx\\dist\\firefox\\firefox.exe', '-no-remote', '-profile', 'c:\\mozbuild\\mozilla-central\\objdir-fx\\_profile\\pgo\\pgoprofile/', 'http://localhost:8888/index.html'] INFO | automation.py | Application pid: 2368 TEST-UNEXPECTED-FAIL | automation.py | Exited with code -1073741819 during test run INFO | automation.py | Application ran for: 0:00:04.143000 INFO | automation.py | Reading PID log: c:\users\ryan\appdata\local\temp\tmpkp2ftcpidlog PROCESS-CRASH | automation.py | application crashed (minidump found) Crash dump filename: c:\mozbuild\mozilla-central\objdir-fx\_profile\pgo\pgoprofile\minidumps\36170e04-2dae-4566-b86c-03db7e9cf267.dmp No symbols path given, can't process dump. Neither MINIDUMP_STACKWALK nor MINIDUMP_STACKWALK_CGI is set, can't process dump. c:\mozbuild\mozilla-central\client.mk:214:0: command 'OBJDIR=c:/mozbuild/mozilla-central/objdir-fx JARLOG_DIR=c:/mozbuild/mozilla-central/objdir-fx/jarlog/en-US python c:/mozbuild/mozilla-central/objdir-fx/_profile/pgo/profileserver.py' failed, return code -1073741819 c:\mozbuild\mozilla-central\client.mk:174:0: command 'c:/mozbuild/python/python.exe c:/mozbuild/mozilla-central/build/pymake/pymake/../make.py -f c:/mozbuild/mozilla-central/client.mk profiledbuild' failed, return code 2
Yep! Spooky how this bug has persisted through three MSVC versions D:
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
File a Microsoft Connect issue on it? I know producing testcases is hard. :-/
Ryan, is this PGO crash still reproducible in VS2015? As of bug 1186064, we no longer support building with VS < 2015.
I don't know, I stopped building with PGO locally awhile ago. Probably best to just push to Try with |mk_add_options MOZ_PGO=1| added to build/mozconfig.common.override and see what happens.
Thanks. Looks like we're stuck with this #ifdef for a while longer. Enabling PGO, with or without reverting the crash reporter #ifdefs, blows up on Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b6388d7ac990&selectedJob=24838679 The taskcluster job fails and the debug build (PGO but not non-PGO!) asserts in WindowsDllBlocklist.cpp: Assertion failure: !sUser32BeforeBlocklist, at c:/builds/moz2_slave/try-w64-d-00000000000000000000/build/src/mozglue/build/WindowsDllBlocklist.cpp:769
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.