6765 - Addresses don't appear in Purify

Status: VERIFIED INVALID

(SeaMonkey :: General, defect, P3)

Description

[David Gardiner]

When trying to use Purify for NT, it complains that NSPR3.DLL contains addresses
that are not in any block.

This is caused by the compilation options chosen in WIN32.mk

I've created a patch that fixed this problem, but should not have any other
residual effects.

-dave

Comment 1

[David Gardiner]

Attachment: Patch for WIN32 config to fix symbols

Comment 2

[srinivas]

Accepted the bug and added cc list.

Comment 3

[srinivas]

Accepted the bug and added cc list.

Comment 4

[srinivas]

Can this problem be reproduced with any of the nspr test programs?
When I tried running a couple of purify'd test programs I did not the see the
"address not contained in any block" error.

Comment 5

[David Gardiner]

I only noticed it when I ran viewer.exe or apprunner.exe under Purify for NT
(I'm using Purify v6.01 build 1607)

Comment 6

[srinivas]

Can you try reproducing this with nspr test programs? I don't have access to
Purify 6.01 (I used Purify 5.0.1 with nspr test programs).

It appears that your patch simply causes the debug information to be stored in
the PDB files, instead of the executable. I don't understand how this fixes the
purify error.

The reason NSPR makefiles were modified to save the debug information in the
executables is that the PDB files don't have to distributed.

Comment 7

[David Gardiner]

Ok, NSPR is being compiled using Mozilla's makefile.win

I actually suspect this is either a bug in MSVC6 or Purify, because I agree,
there shouldn't be any difference if the symbols are in the object file, or in a
separate PDB file. Unfortunately, it seems that if the symbols get included in
the object file, then Purify can't figure some of them out.

Running Purify on string.exe (without generating PDB files) , I get the
following:

Purify for Windows NT,
Copyright (C) 1992-1998 Rational Software Corporation All rights reserved.
Version 6.0.1; Build: 1607; Product key:
Instrumenting:
	  string.exe   57430 bytes
	  NSPR3.DLL    659028 bytes

Purify: While processing file
D:\mozilla_src\mozilla\dist\WIN32_D.OBJ\bin\NSPR3.DLL:
Warning: Address 0x30031930 does not appear to be in any block.

Purify: Warning: Address 0x30031944 does not appear to be in any block.

Purify: Warning: Address 0x30031958 does not appear to be in any block.

Purify: Warning: Address 0x3003196c does not appear to be in any block.

Purify: Warning: Address 0x30031980 does not appear to be in any block.

BUT, when I make NSPR on its own, using just gmake, instead of nmake -f
makefile.win, then I can run Purify ok, and it is quite happy about the DLL's.

There must be something about the differences between how Mozilla builds NSPR
and the internal way of building NSPR.

-dave

Comment 8

[Wan-Teh Chang]

There are two ways to build NSPR on Win32:
From mozilla\nsprpub:
1. gmake OS_TARGET=WIN95 [BUILD_OPT=1]: default
   is debug build.  Specify BUILD_OPT=1 to get
   optimized build.
2. nmake -f makefilw.win: I believe the default
   is optimized build and you need to set MOZ_DEBUG
   to get debug build.

Are these the commands you used?

Comment 9

[srinivas]

This bug should be closed as invalid as the default build of NSPR doesn't result
in the purify errors.

Comment 10

[David Gardiner]

Building NSPR the default way (ie. the way that Mozilla makes it) does result in
errors for Purify 6.01. I don't know if it is a bug in Purify or in VC6, but
there it is.

Comment 11

[srinivas]

It is important to note that NSPR is built and maintained as a standalone
library; the default way to build it is as a standalone library.

When NSPR is built along with a product using a different set of compiler/linker
flags, it is not being built in the default method.

This bug is being assigned to Chris Hofmann for further debugging into Mozilla's
build environment.

Comment 12

[chris hofmann]

marking invalid as a seamonkey bug since it sounds like
this is vc6 or purify

Comment 13

[Jay Patel [:jay]]

verified invalid