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

Accepted the bug and added cc list.

Accepted the bug and added cc list.

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.

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

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.

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

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?

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

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.

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.

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

verified invalid