Closed Bug 555485 Opened 10 years ago Closed 9 years ago

[Win2K] "debug_util_win.cc(262) : error C3861: 'CaptureStackBackTrace': identifier not found"

Categories

(Core :: IPC, defect, blocker)

x86
Windows 2000
defect
Not set
blocker

Tracking

()

RESOLVED WONTFIX
mozilla2.0b8
Tracking Status
blocking2.0 --- -

People

(Reporter: sgautherie, Assigned: sgautherie)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

After tracemonkey bug 549207 fix,
I discovered I currently have to add --disable-ctypes for bug 551724,
then my local build fails later with:
{
.../ipc/chromium/src/base/debug_util_win.cc(262) : error C3861: 'CaptureStackBackTrace': identifier not found
}

I don't know why I now hit this :-(

Code is
{
261   // TODO(ajwong): Migrate this to StackWalk64.
262   int count = CaptureStackBackTrace(0, kMaxCallers, callers, NULL);
}

http://msdn.microsoft.com/en-us/library/bb204633(VS.85).aspx
{
Minimum supported client	Windows XP
Minimum supported server	Windows Server 2003
}

Obviously, I should not be building this code.

NB: I have VS8E and 2003R2 SDK.
(In reply to comment #0)
> I don't know why I now hit this :-(

Oh, I must not have built Firefox since
http://hg.mozilla.org/mozilla-central/rev/fc6ed914e44e
"Build the pieces of the chromium code we actually need. Many thanks to bent for doing this the first time: I redid the Makefile to be all in one directory and use vpath directives so that dependencies work correctly."

--disable-ipc lets my build complete.

Then, either this code needs to be fixed, or an explicit check added in configure.in until then.
Severity: blocker → minor
Flags: in-testsuite-
Component: General → IPC
Keywords: regression
QA Contact: general → ipc
Duplicate of this bug: 558559
Summary: "debug_util_win.cc(262) : error C3861: 'CaptureStackBackTrace': identifier not found" → [Win2K] "debug_util_win.cc(262) : error C3861: 'CaptureStackBackTrace': identifier not found"
(In reply to comment #2)
> *** Bug 558559 has been marked as a duplicate of this bug. ***

Back to blocker, per that bug.
Severity: minor → blocker
Not sure I understand why this is nominated.  Can you explain?  Clearing for now, but please re-nom with a detailed reason.
blocking2.0: ? → ---
5,5 months without being able to run Debug Firefox builds:
not helpful when trying to check/fix tests :-(
status2.0: --- → ?
blocking2.0: --- → -
status2.0: ? → ---
Blocks: 562820
Ftr,
SeaMonkey has just switched to libxul (bug 394502) then enabled ipc (bug
545716).
I downloaded a Debug Windows build and I'm now seeing this bug instead of
bug 562820.
We do not intend to make debug builds work on win2k. The only thing I would accept for this bug is a configure patch requiring a new-enough version of the Windows SDK.
Blocks: 558559
Per your comment 7.
Assignee: nobody → sgautherie.bz
Status: NEW → ASSIGNED
Attachment #478696 - Flags: review?(benjamin)
Blocks: 599893
NS_ENABLE_TSF will be further sorted out in bug 599893.
Attachment #478696 - Attachment is obsolete: true
Attachment #478810 - Flags: review?(ted.mielczarek)
Attachment #478696 - Flags: review?(benjamin)
Comment on attachment 478810 [details] [diff] [review]
(Av2) configure.in: be more explicit and stricter when building without needed Windows SDK
[Backed out: See comment 19]

>+if test -n "$COMPILE_ENVIRONMENT"; then
>+dnl ========================================================
>+dnl = (Windows) Text Services Framework
>+dnl ========================================================
>+case "$target_os" in
>+    msvc*|mks*|cygwin*|mingw*)
>+        if test -z "$GNU_CC" -a -n "$NS_ENABLE_TSF" -a "$MOZ_WINSDK_TARGETVER" -lt "06000000"; then
>+            # (We chose to assume that) TSF is a Windows Vista SDK (or newer) feature. (See bug 88831 comment 135)
>+            AC_MSG_ERROR([TSF can't be built with your SDK which only supports Windows up to version $MOZ_WINSDK_MAXVER. Install and use Windows Vista SDK or newer, or do not set NS_ENABLE_TSF=1. Alternatively, try running the Windows SDK Configuration Tool and selecting a newer SDK. See https://developer.mozilla.org/En/Windows_SDK_versions for more details on fixing this.])

Instead of saying "do not set X", you should give the option that the user needs to use to avoid this error, like "you can specify --disable-whatever". Please fix that in all of your error messages.

r=me with that change.
Attachment #478810 - Flags: review?(ted.mielczarek) → review+
Comment on attachment 478810 [details] [diff] [review]
(Av2) configure.in: be more explicit and stricter when building without needed Windows SDK
[Backed out: See comment 19]

(In reply to comment #10)

Your comment makes sense, but I'm not sure that it applies to these cases.

1)
There is currently no '--*able-tsf'.
2)
Correct default values are/would_be set: see the 'AC_MSG_WARN()' blocks.
Then, if the user is getting errors, it's only because he tried to override them, when he shouldn't.
So, specifying '--disable-*' would just be redundant with the defaults.

In other words, I would agree with you if we removed the defaults and forced the user to explicitly disable these features, but I don't think we want to cause this burden.
Attachment #478810 - Flags: feedback?(ted.mielczarek)
Comment on attachment 478810 [details] [diff] [review]
(Av2) configure.in: be more explicit and stricter when building without needed Windows SDK
[Backed out: See comment 19]

Ok, that's fine then.
Attachment #478810 - Flags: feedback?(ted.mielczarek) → feedback+
Comment on attachment 478810 [details] [diff] [review]
(Av2) configure.in: be more explicit and stricter when building without needed Windows SDK
[Backed out: See comment 19]

"approval2.0=?":
Configure fixes for building with older SDK, no risk.
Attachment #478810 - Flags: approval2.0?
Comment on attachment 478810 [details] [diff] [review]
(Av2) configure.in: be more explicit and stricter when building without needed Windows SDK
[Backed out: See comment 19]

http://hg.mozilla.org/mozilla-central/rev/2313b1b0e0d5
Av2, with sorted OS list and not adding cygwin.
Attachment #478810 - Attachment description: (Av2) configure.in: be more explicit and stricter when building without needed Windows SDK → (Av2) configure.in: be more explicit and stricter when building without needed Windows SDK [Checked in: See comment 14]
Attachment #478810 - Flags: approval2.0?
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
I backed out all the changesets in your push because they weren't approved.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment on attachment 478810 [details] [diff] [review]
(Av2) configure.in: be more explicit and stricter when building without needed Windows SDK
[Backed out: See comment 19]

(In reply to comment #15)
> I backed out all the changesets in your push because they weren't approved.

See discussion in bug 595756 :-<
Attachment #478810 - Flags: approval2.0?
(In reply to comment #4)
> Not sure I understand why this is nominated.  Can you explain?

It was nominated because build fails on a tier-1 platform :-<
Attachment #478810 - Attachment description: (Av2) configure.in: be more explicit and stricter when building without needed Windows SDK [Checked in: See comment 14] → (Av2) configure.in: be more explicit and stricter when building without needed Windows SDK [Checked in: See comment 14]
Attachment #478810 - Flags: approval2.0? → approval2.0-
Too late, don't care. We're just going to bump the minimum supported platform post-4.0.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → WONTFIX
(In reply to comment #15)
> I backed out all the changesets in your push because they weren't approved.

http://hg.mozilla.org/mozilla-central/rev/43dc221c45ad
Attachment #478810 - Attachment description: (Av2) configure.in: be more explicit and stricter when building without needed Windows SDK [Checked in: See comment 14] → (Av2) configure.in: be more explicit and stricter when building without needed Windows SDK [Backed out: See comment 19]
Bug 639754 removed 'MOZ_IPC', which is always 'on' now.
Depends on: 639754
Depends on: PSDK2003R2Removal
(In reply to Serge Gautherie (:sgautherie) from comment #0)
> .../ipc/chromium/src/base/debug_util_win.cc(262) : error C3861:
> 'CaptureStackBackTrace': identifier not found
> }

Ftr, there is another affected file:
{
process_util_win.cc
.../ipc/chromium/src/base/process_util_win.cc(560) : error C2065: 'PSAPI_WORKING_SET_INFORMATION' : undeclared identifier
...
.../ipc/chromium/src/base/process_util_win.cc(737) : error C2065: 'HeapEnableTerminationOnCorruption' : undeclared identifier
}

NB: I have a bare workaround for both, locally...
And a 3rd/last error, on Debug builds:
something like "firefox.exe : Missing entry point SymFromAddr in dbghelp.dll"

This one is in debug_util_win.cc too.

NB: I have a bare workaround for it too locally, and I can build a runnable debug Firefox from Try with it, at last :-)
Depends on: RequireWin7SDK
No longer depends on: PSDK2003R2Removal
You need to log in before you can comment on or make changes to this bug.