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

RESOLVED WONTFIX

Status

()

--
blocker
RESOLVED WONTFIX
9 years ago
7 years ago

People

(Reporter: sgautherie, Assigned: sgautherie)

Tracking

(Blocks: 1 bug)

Trunk
mozilla2.0b8
x86
Windows 2000
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(blocking2.0 -)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

9 years ago
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.
(Assignee)

Comment 1

9 years ago
(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-
(Assignee)

Updated

9 years ago
Component: General → IPC
Keywords: regression
QA Contact: general → ipc
(Assignee)

Updated

9 years ago
Duplicate of this bug: 558559
(Assignee)

Updated

9 years ago
Summary: "debug_util_win.cc(262) : error C3861: 'CaptureStackBackTrace': identifier not found" → [Win2K] "debug_util_win.cc(262) : error C3861: 'CaptureStackBackTrace': identifier not found"
(Assignee)

Comment 3

9 years ago
(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: ? → ---
(Assignee)

Comment 5

8 years ago
5,5 months without being able to run Debug Firefox builds:
not helpful when trying to check/fix tests :-(
status2.0: --- → ?

Updated

8 years ago
blocking2.0: --- → -
status2.0: ? → ---
(Assignee)

Updated

8 years ago
Blocks: 562820
(Assignee)

Comment 6

8 years ago
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.

Comment 7

8 years ago
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.
(Assignee)

Updated

8 years ago
Blocks: 558559
(Assignee)

Comment 8

8 years ago
Created attachment 478696 [details] [diff] [review]
(Av1) configure.in: error out when trying to build IPC support without Windows Vista SDK or newer

Per your comment 7.
Assignee: nobody → sgautherie.bz
Status: NEW → ASSIGNED
Attachment #478696 - Flags: review?(benjamin)
(Assignee)

Updated

8 years ago
Blocks: 599893
(Assignee)

Comment 9

8 years ago
Created attachment 478810 [details] [diff] [review]
(Av2) configure.in: be more explicit and stricter when building without needed Windows SDK
[Backed out: See comment 19]

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+
(Assignee)

Comment 11

8 years ago
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+
(Assignee)

Comment 13

8 years ago
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?
(Assignee)

Comment 14

8 years ago
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?
(Assignee)

Updated

8 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 8 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 → ---
(Assignee)

Comment 16

8 years ago
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?
(Assignee)

Comment 17

8 years ago
(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 :-<

Updated

8 years ago
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
Last Resolved: 8 years ago8 years ago
Resolution: --- → WONTFIX
(Assignee)

Comment 19

8 years ago
(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
(Assignee)

Updated

7 years ago
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]
(Assignee)

Comment 20

7 years ago
Bug 639754 removed 'MOZ_IPC', which is always 'on' now.
Depends on: 639754
(Assignee)

Updated

7 years ago
Depends on: 629827
(Assignee)

Comment 21

7 years ago
(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...
(Assignee)

Comment 22

7 years ago
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 :-)
(Assignee)

Updated

7 years ago
Depends on: 699385
No longer depends on: 629827
You need to log in before you can comment on or make changes to this bug.