Purify problems...?

We had used purify 4.5 previously on Solaris 2.5 and 2.6 with excellent results. We're not trying to use purify 5.1 and 5.2 on solaris 2.6 or 2.7 and having terrible results. Lots of flaky error reporting on things that near as any of us can tell are indeed not errors. Same code under 4.5 on solaris 2.6 has no problems.
Is anyone else having luck with purify 5.x??
Matt

I should have mentioned, we're using Sun's C++ 5.0.

Similar Messages

Purify problem or compiler problem?

Hi,
I am using sun's CC (c++ compiler) to compile the follow code:
#define __REENTRANT
#include <stdio.h>
#include <pthread.h>
void one(void dummy);
void two(void);
void output(void);
int main (int argc, char **argv)
pthread_t tid;
pthread_create( &tid, NULL, one, NULL );
pthread_join(tid,NULL);
void one(void dummy)
output();
two();
return NULL;
void two(void)
output();
void output(void)
//char string[16468]; //This one purify likes
//char string[16469]={0}; //This and greater makes purify spit
BSW's
char string[16469]; //This and greater makes purify spit a
IPW/R's
string[0]='\0';
This is purify's output:
IPW: Invalid pointer write
This is occurring while in thread 7:
void output() [testmain3.o]
void two() [testmain3.o]
void*one(void*) [testmain3.o]
threadstart [libthread.so.1]
Writing 1 byte to 0x7e5fbbef on the stack of thread 7.
Address 0x7e5fbbef is 16473 bytes below frame pointer in
function void output().
Thread Summary : 7 threads in existence
Thread 0 [main thread]
Stack Limit : (0xff3f0000 0xffbf0000), size = 0x800000
Thread 1
Stack Limit : (0x7ef10000 0x7f010000), size = 0x100000
Stack Use : (0x7f00fa30 0x7f00fd54), size = 0x324
Thread 2
Stack Limit : (0x7e652000 0x7e656000), size = 0x4000
Stack Use : (0x7e655978 0x7e655d54), size = 0x3dc
Thread 3
Stack Limit : (0x7f902b64 0x7f91e3f8), size = 0x1b894
Stack Use : (0x7f9076d0 0x7f9078f4), size = 0x224
Thread 4
Stack Limit : (0x7ee0e000 0x7ef0e000), size = 0x100000
Stack Use : (0x7ef0db30 0x7ef0dd54), size = 0x224
Thread 6
Stack Limit : (0x7e612000 0x7e616000), size = 0x4000
Stack Use : (0x7e615b28 0x7e615d54), size = 0x22c
Thread 8
Stack Limit : (0x7e632000 0x7e634000), size = 0x2000
Stack Use : (0x7e633b28 0x7e633d54), size = 0x22c
This is with CC. With gcc or g++ it does not have this problem. cc has
the problem too but with a larger number in the array.
Is it the compiler/linker bug or it purify making things up?
If it is the compiler I assume I am screwing up memory badly.
Matt
P.S the program compiles and links and runs with no problems. And there is no optimizations

1. You didn't mention what compiler version you are using.
I compiled using Sun One Studio 8, Compiler Collection with no error.
2. Sorry that we at Sun don't provide or support Purify. If you are having trouble using Purify, please ask Purify about it. They can tell you how best to use their product on Solaris using Sun compilers.
- Rose

Purify'ing CORBA applications

I have been trying to purify a Tuxedo CORBA application with not much luck. Hoping
somebody can help.
OS : SunOS 5.8
Tuxedo: 8.0
Purify: 2003.06.00 Solaris 2
I set the following environment variables before building the application
CC=/app/Rational/releases/purify.sol.2003.06.00/purify /net/pdcnfs01/share/nfs01/software02/SUNWspro6.0/WS6U2/bin/CC
CFLAGS=-g -mt -w -pic
I compiled the simpapp (corba application) that came with tuxedo and tried booting
up the server. Initially I got an error specifying that it could not find the
following library:
ld.so.1: simple_server: fatal: libenv.so.71_pure_p3_c0_111202132_58_32: open failed:
No such file or directory
So I modified LD_LIBRARY_PATH to $LD_LIBRARY_PATH:/app/Rational/releases/purify.sol.2003.06.00/cache/app/tuxedo/tuxedo8.0/lib
That seemed to solve that problem. But now when the server comes up, it dumps
core.
This is what the stack looks like.. (from dbx; where -h)
current thread: t@1
[1] xkill(0x0, 0x6, 0x0, 0x5, 0xffbee870, 0x0), at 0x771fc
[2] pure_signal_handler_wrapper(0x6, 0xffbeebc8, 0xffbee910, 0xfdb1801c, 0x1faf4,
0xfda6c028), at 0x5090c
[3] pure_sigtramp(0x6, 0x0, 0x0, 0xffffffff, 0x149a68, 0x0), at 0x74040
[4] abort(0xfdb1801c, 0x3fc3b151, 0x14f74, 0xfe895110, 0xff0ebe08, 0x0), at
0xfda48d24
[5] __Cimpl::ex_terminate(0x0, 0x20, 0xfe9134f8, 0x0, 0x0, 0x0), at 0xff0d849c
[6] __Crun::ex_throw(0xff0edd88, 0xfec1d2d4, 0xfe8dd218, 0x0, 0xff0ec544, 0x0),
at 0xff0d40b0
[7] CORBA::BAD_PARAM::_raise(0x14ad10, 0xfec4acc4, 0xffbeeee8, 0x1813a, 0xffbeef50,
0x0), at 0xfe8dd5ec
[8] ErrorInfo::RaiseExceptionIfError(0x14ad10, 0xffbeeee8, 0xfec4acc4, 0x128aec,
0xffbeef50, 0xfec5b30c), at 0xfe9134f0
[9] TypeCodeImpl::TypeCodeImpl(0xffbeef50, 0xfec5b2f0, 0x0, 0x0, 0xfec4acc4,
0x0), at 0xfe908c8c
[10] __STATIC_CONSTRUCTOR(0xfec4acc4, 0xfec5ba40, 0x0, 0xff0edcf0, 0x293b0,
0xff3bdd04), at 0xfe8d8c18
[11] _init(0x0, 0xff3e2660, 0x1, 0xff3e2660, 0x0, 0x0), at 0xfebf0a10
[12] call_init(0xff0a0f94, 0x1, 0xff3e21f0, 0xff3e2660, 0x400000, 0xff0a0ff0),
at 0xff3bad80
[13] setup(0xff3a0018, 0xff3e2000, 0xff3e20d0, 0xff3e3c30, 0xff3e2030, 0xff3e2660),
at 0xff3ba9f8
[14] _setup(0xd4, 0xff3e2660, 0xff3a0018, 0x5, 0x100d4, 0x0), at 0xff3c4d58
[15] rtboot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xff3b2938
I got the same exception when I tried to run the client piece too.
Any help would be greatly appreciated.

This looks like a Purify problem. I have run Purify for Windows without problem
against Tuxedo on a regular basis. Are you sure you are running the latest version
of Purify and have the proper Purify for you compiler and OS version? Can you
try running your application on Windows and try using Purify for Windows?
Basically what you are encountering is an exception being thrown during the static
initialization of a typecode. This is typically done in our stubs. Why you would
be getting a BAD_PARAM is beyond me. Have you compiled all the code with the
same version of the compiler and is your compiler up to date?
-tl
-tl
"A Marcose" <[email protected]> wrote:
>
I have been trying to purify a Tuxedo CORBA application with not much
luck. Hoping
somebody can help.
OS : SunOS 5.8
Tuxedo: 8.0
Purify: 2003.06.00 Solaris 2
I set the following environment variables before building the application
CC=/app/Rational/releases/purify.sol.2003.06.00/purify /net/pdcnfs01/share/nfs01/software02/SUNWspro6.0/WS6U2/bin/CC
CFLAGS=-g -mt -w -pic
I compiled the simpapp (corba application) that came with tuxedo and
tried booting
up the server. Initially I got an error specifying that it could not
find the
following library:
ld.so.1: simple_server: fatal: libenv.so.71_pure_p3_c0_111202132_58_32:
open failed:
No such file or directory
So I modified LD_LIBRARY_PATH to $LD_LIBRARY_PATH:/app/Rational/releases/purify.sol.2003.06.00/cache/app/tuxedo/tuxedo8.0/lib
That seemed to solve that problem. But now when the server comes up,
it dumps
core.
This is what the stack looks like.. (from dbx; where -h)
current thread: t@1
[1] xkill(0x0, 0x6, 0x0, 0x5, 0xffbee870, 0x0), at 0x771fc
[2] pure_signal_handler_wrapper(0x6, 0xffbeebc8, 0xffbee910, 0xfdb1801c,
0x1faf4,
0xfda6c028), at 0x5090c
[3] pure_sigtramp(0x6, 0x0, 0x0, 0xffffffff, 0x149a68, 0x0), at 0x74040
[4] abort(0xfdb1801c, 0x3fc3b151, 0x14f74, 0xfe895110, 0xff0ebe08,
0x0), at
0xfda48d24
[5] __Cimpl::ex_terminate(0x0, 0x20, 0xfe9134f8, 0x0, 0x0, 0x0), at
0xff0d849c
[6] __Crun::ex_throw(0xff0edd88, 0xfec1d2d4, 0xfe8dd218, 0x0, 0xff0ec544,
0x0),
at 0xff0d40b0
[7] CORBA::BAD_PARAM::_raise(0x14ad10, 0xfec4acc4, 0xffbeeee8, 0x1813a,
0xffbeef50,
0x0), at 0xfe8dd5ec
[8] ErrorInfo::RaiseExceptionIfError(0x14ad10, 0xffbeeee8, 0xfec4acc4,
0x128aec,
0xffbeef50, 0xfec5b30c), at 0xfe9134f0
[9] TypeCodeImpl::TypeCodeImpl(0xffbeef50, 0xfec5b2f0, 0x0, 0x0, 0xfec4acc4,
0x0), at 0xfe908c8c
[10] __STATIC_CONSTRUCTOR(0xfec4acc4, 0xfec5ba40, 0x0, 0xff0edcf0,
0x293b0,
0xff3bdd04), at 0xfe8d8c18
[11] _init(0x0, 0xff3e2660, 0x1, 0xff3e2660, 0x0, 0x0), at 0xfebf0a10
[12] call_init(0xff0a0f94, 0x1, 0xff3e21f0, 0xff3e2660, 0x400000, 0xff0a0ff0),
at 0xff3bad80
[13] setup(0xff3a0018, 0xff3e2000, 0xff3e20d0, 0xff3e3c30, 0xff3e2030,
0xff3e2660),
at 0xff3ba9f8
[14] _setup(0xd4, 0xff3e2660, 0xff3a0018, 0x5, 0x100d4, 0x0), at 0xff3c4d58
[15] rtboot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xff3b2938
I got the same exception when I tried to run the client piece too.
Any help would be greatly appreciated.

Solaris 8 - Motif, Xbae apps ZPR with purify or Bus error

The application runs under 5.6 but after compiling and running on 5.8, I receive a Bus Error or when running purify receive a ZPR & COR. The c program is receiving the error during widget creation:
tbl = XtVaCreateManagedWidget
("tbl",
xbaeMatrixWidgetClass, parent, ...... etc.)
Purify outputs this message:
ZPR: This is occurring while in:
_XtCompileCallbackList [Callback.c]
CompileCallbacks [Create.c]
xtCreate [Create.c]
_XtVaCreateWidget [VarCreate.c]
XtVaCreateManagedWidget [VarCreate.c]
Reading 4 bytes from 0x12
I have tended to think I have a versioning problem with Solaris 8 but I need some help.
Thank you very much, Joanne

The application runs under 5.6 but after compilingand
running on 5.8, I receive a Bus Error or whenrunning
purify receive a ZPR & COR. The c program is
receiving the error during widget creation:
tbl = XtVaCreateManagedWidget
("tbl",
xbaeMatrixWidgetClass, parent, ......
, parent, ...... etc.)
Purify outputs this message:
ZPR: This is occurring while in:
_XtCompileCallbackList[Callback.c]
CompileCallbacks [Create.c]
xtCreate [Create.c]
_XtVaCreateWidget [VarCreate.c]
XtVaCreateManagedWidget
ateManagedWidget [VarCreate.c]
Reading 4 bytes from 0x12
I have tended to think I have a versioning problem
with Solaris 8 but I need some help.
Thank you very much, Joanne

Memory increase problem on Solaris

We need your help in understanding and solving a memory problem in one of our products running on Soalris. The server memory keeps growing and there is a fear of a server crash.
We've run our product with Purify and libumem to identify memory leaks. Both of these products didn't report any leak. So, we are very much confident that there are no memory leaks in the product. Still the memory increase is seen on Unix systems. We've done extensive analysis on this subject and absorbed some key points regarding memory management in Unix.
1) Memory doesn't shrink on Unix systems. This is for the libc to retain the released memory and reuse it for further memory requirements.
2) Based on the memory requirements to our application there can be a stabilization point where in the application can serve all memory requests.
After reaching this point the Server memory doesn't increase.But the fear is that it may exceed the hardware resources constraint.
3) Rapid increase in memory can be because of Memory Fragmentation problem. There are environmental variables like Small Block Allocator (_M_SBA_OPTS) and Arena (_M_ARENA_OPTS) on HP-Unix machines which can be used to address Fragmentation issues. We've performed some tests using these variables and found significant improvement in the usage of memory. This confirms that there are no memory leaks. These variables are specific to HP-Unix machines and we are unaware of similar variables/mechanism on Sun Solaris Platform. Please recommend some environmental variables/mechanism on Sun Solaris platform to solve fragmentation problem.
We are performing some tests to observe memory stabilization over a period of time .
The memory bloat is following a pattern. Memory is increasing in chunks of (MB) 2,4,8,16,32,64,128,256,512,1024 MB pattern.
For example if Memory increase is 64 MB, then it stabilizes for some time and the next increase would be 128 MB at a time.
Then it stabilizes for double the time consumed earlier for 64 MB and after that only increases by 256 MB.
So the memory increase and stabilization time are getting doubled each time. Please validate our analysis and kindly suggest what can be done on Unix platforms for solving this memory increase problem.

Thanks MaximKartashev for your inputs.
Ours is a Multithreading application. We are testing it with Hoard for the last three days. The observation so far has been that the performance of Hoard is high but the bloat pattern is not avoided.
Even with Hoard, memory bloat is following a pattern. Memory is increasing in chunks of (MB) 2,4,8,16,32,64,128,256,512,1024 MB pattern.
We are searching for other ways to control this pattern and stabilize the application by making it to reuse the fragmented memory completely.
We have also tried Solaris libgc memory allocator (http://developers.sun.com/solaris/articles/libgc.html). It worked well initially and memory drop was seen. But on heavy load, it crashed the application with 'Can't allocate header' error. So this can't be used for heavy load.
We are trying to use Boehm-Demers-Weiser Garbage Collector (http://www.hpl.hp.com/personal/Hans_Boehm/gc/). Do any one have idea, if it controls memory fragmentation ?

Coredump under Purify

I wrote a C++ application that uses the OCI to run queries and print the fetched data. It works fine, but when I try to run it under Purify, I get a ZPR followed by a core dump on the call to OCIDescriptorAlloc().
Because I couldn't be sure whether the problem was something in my program, I simplified the code down to the line that seems to be triggering the core dump, plus an OCIEnvCreate (since OCIDecriptorAlloc() needs an environment handle) along with a few informational printf()s, and it still dumps core.
I'm running on Solaris 2.8 using PurifyPlus-2003a.06.00 with gcc/g++ 3.3.1 and Oracle 10g client (32-bit libs). In this program, I need a timestamp descriptor, but I tried the same code with other types of descriptors. Snapshop, LOB, and RowID descriptors run fine under Purify, but Date, Timestamp, Interval, and ComplexObjectComp ones all coredump.
Without Purify, everything is fine; no crashes or other problems. But as I need to incorporate this into a multithreaded application, being able to use Purify is essential.
The simplified program is short, so I'll paste it here:
#include <stdio.h>
#include <oci.h>
#include <orl.h>
main()
sword rc;
OCIEnv *env = NULL;
OCIDateTime *dtval = NULL;
rc = OCIEnvCreate(&env, OCI_OBJECT, (void *) 0, 0, 0, 0, (size_t) 0, (void **) 0);
if (rc != OCI_SUCCESS && rc != OCI_SUCCESS_WITH_INFO)
fprintf(stderr, "Error creating environment\n");
else printf("Env created: %ld\n", env);
rc = OCIDescriptorAlloc((void *) env, (void **) &dtval, OCI_DTYPE_TIMESTAMP, 0, NULL);
if (rc != OCI_SUCCESS && rc != OCI_SUCCESS_WITH_INFO)
fprintf(stderr, "Error allocating descriptor\n");
else printf("Descriptor allocated\n");
rc = OCIDescriptorFree((void *) dtval, OCI_DTYPE_TIMESTAMP); // This is where it coredumps.
if (rc != OCI_SUCCESS && rc != OCI_SUCCESS_WITH_INFO)
fprintf(stderr, "Error freeing descriptor\n");
else printf("Descriptor freed\n");
Compile lines:
purify g++ -g -Wall -I/export/home/oracle/product/10.1.0/db_1/rdbms/public -I/export/home/oracle/product/10.1.0/db_1/plsql/public -I/cm/tools/paks/PurifyPlus-2003a.06.00/releases/purify.sol.2003a.06.00 -I../../include -c otest.cpp
otest.cpp:6: warning: ISO C++ forbids declaration of `main' with no type
purify g++ -g -Wall -o otest otest.o -lclntsh -L/export/home/oracle/product/10.1.0/db_1/lib32 -L/export/home/oracle/product/10.1.0/db_1/rdbms/lib32 -L/cm/tools/paks/PurifyPlus-2003a.06.00/releases/purify.sol.2003a.06.00/lib32 -lm
Purify output:
**** Purify instrumented otest (pid 4992 at Tue Apr 26 14:50:17 2005)
* Purify 2003a.06.00 Solaris 2 (32-bit) Copyright (C) 1992-2003 Rational Software Corp. All rights reserved.
* For contact information type: "purify -help"
* For Purify Viewer output, set the DISPLAY environment variable.
* Options settings: -max_threads=200 \
-cache-dir=/export/home/tmancuso/harvester/src/.purify.cache -best-effort \
-g++=yes -purify \
-purify-home=/cm/tools/paks/PurifyPlus-2003a.06.00/releases/purify.sol.2003a.06.00 \
-gcc3_path=/cm/tools/apps/bin/../../paks/gcc-3.3.1/bin/g++ \
-cache-dir=/export/home/tmancuso/harvester/src/.purify.cache \
-demangle_program=/cm/tools/apps/bin/../../paks/gcc-3.3.1/bin/c++filt \
-threads=yes -use-internal-locks=yes -thread_stack_change=0x4000 \
-mt_safe_malloc=yes
* License successfully checked out.
* Command-line: otest
**** Purify instrumented otest (pid 4992) ****
UMR: Uninitialized memory read:
* This is occurring while in:
kouogini [kouo.c]
kouoini [kouo.c]
kpuinit0 [kpuini.c]
kpuenvcr [kpuini.c]
OCIEnvCreate [oci8.c]
main [otest.cpp:11]
* Reading 4 bytes from 0xffbee34c on the stack.
* Address 0xffbee34c is 308 bytes below frame pointer in function kouogini.
**** Purify instrumented otest (pid 4992) ****
UMR: Uninitialized memory read:
* This is occurring while in:
kpminit [kpm.c]
kpuinit0 [kpuini.c]
kpuenvcr [kpuini.c]
OCIEnvCreate [oci8.c]
main [otest.cpp:11]
_start         [crt1.o]
* Reading 4 bytes from 0xffbee46c on the stack.
* Address 0xffbee46c is 132 bytes below frame pointer in function kpminit.
Env created: 1290920
**** Purify instrumented otest (pid 4992) ****
ZPR: Zero page read:
* This is occurring while in:
kpugdesc [kpuini.c]
main [otest.cpp:16]
_start         [crt1.o]
* Reading 4 bytes from 0x26c4
**** Purify instrumented otest (pid 4992) ****
COR: Fatal core dump:
* This is occurring while in:
kpugdesc [kpuini.c]
main [otest.cpp:16]
_start         [crt1.o]
* Received signal 11 (SIGSEGV - Segmentation Fault)
* Faulting address = 0x26c4
* Signal mask: (SIGSEGV)
* Pending signals:
Segmentation Fault(coredump)
Thanks,
--Tina

Have you had any luck so far?
Nope. The best I could manage was a workaround -- I used #ifndefs to make the sections of code dealing with timestamps not compile if Purify is being used. It's dangerous to do that and it makes your output come out wrong (all timestamps will just be blank fields), but I couldn't think of any other way to deal with it.
(Sorry for the late reply; I only just saw this now.)

Forte 62, Solaris Compiler error with purify

Hi all;
I am using a Solaris 2.8 machine, a Forte62 compiler in 64 bit mode.
I have set all LD_LIBRARY_PATH up and it compiles most my code till it gets to the part that it purifies. It gives me this error:
ld: fatal: relocation error: R_SPARC_DISP64: file /purifycache/vob/tools_SunOS/Forte6U2/WS6U2/lib/v9/crti_pure_p3_c0_111202109_64.o: symbol exshared0: offset 0xffffffff7a6faeb4 is non-aligned
Any ideas on what is causing this?
Thanks a mill
Ter

The problem appears to be in purify code. You should contact their tech support.

Purify error with std::string, -xarch=v8plusa -mt

Using WS6U2, latest patches, on Solaris 8 with latest patch cluster (as of a few days ago):
string.cpp:
#include <string>
using namespace std;
int main(int argc, char * argv[])
   string val1 = "hello";
   string val2 = "world";
   string copy( val1 );
   copy = val2;
   return 0;
CC -V
CC: Sun WorkShop 6 update 2 C++ 5.3 Patch 111685-12 2002/12/16
purify -versionVersion 2002a.06.00 Solaris 2
purify -always-use-cache-dir -cache-dir=`pwd`/cache CC -g -xarch=v8plusa -mt string.cpp -o stringAnd we get some rather nasty errors: three Free Memory Reads, two Free Memory Writes, and one Freeing Unallocated Memory. However, remove either of the "-mt" or "-xarch=v8plusa" options, and all is well - no memory errors at all. So it seems that this problem only affects the multithreaded v8plusa specific implementation of std::string.
In the case where it fails ("-mt -xarch=v8plusa"), purify complains as follows:
**** Purify instrumented string (pid 13888 at Tue Feb 18 16:42:31 2003)
* Purify 2002a.06.00 Solaris 2 (32-bit) Copyright (C) 1992-2002 Rational Software Corp. All rights reserved.
* For contact information type: "purify -help"
* For TTY output, use the option "-windows=no"
* Command-line: ./string
* Options settings: -max-threads=2500 -follow-child-processes=yes \
-leaks-at-exit=yes -chain-length=16 -report-pmrs=yes -threads=yes -purify \
-always-use-cache-dir \
-cache-dir=/home/rational/src/experiments/string/cache \
-purify-home=/usr/local/software/rational/releases/purify.sol.2002a.06.00 \
-threads=yes -use-internal-locks=yes -thread_stack_change=0x4000 \
-mt_safe_malloc=yes
* License successfully checked out.
* Command-line: ./string
**** Purify instrumented string (pid 13888) ****
FMR: Free memory read:
* This is occurring while in:
     long __rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> >::__references()const [string_ref:193]
     void std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__unLink() [string:913]
     std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string() [string:297]
     main [string.cpp:15]
     _start         [crt1.o]
* Reading 4 bytes from 0xa6d30 in the heap.
* Address 0xa6d30 is 24 bytes into a freed block at 0xa6d18 of 47 bytes.
* This block was allocated from:
     malloc [rtlib.o]
     c2n6Fi_Pv___1 [libCrun.so.1]
     void*operator new(unsigned) [rtlib.o]
     __rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> >*std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__getRep(unsigned,unsigned) [libCstd.so.1]
     std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string(const char*,const std::allocator<char>&) [libCstd.so.1]
     main [string.cpp:9]
     _start         [crt1.o]
* There have been 0 frees since this block was freed from:
     free [rtlib.o]
     c2k6FPv_v___1 [libCrun.so.1]
     void operator delete(void*) [rtlib.o]
     std::basic_string<char,std::char_traits<char>,std::allocator<char> >&std::basic_string<char,std::char_traits<char>,std::allocator<char> >::operator=(const std::basic_string<char,std::char_traits<char>,std::allocator<char> >&) [libCstd.so.1]
     main [string.cpp:13]
     _start         [crt1.o]
**** Purify instrumented string (pid 13888) ****
FMR: Free memory read:
* This is occurring while in:
     pthread_mutex_destroy [libthread.so.1]
     RWSTDMutex::~RWSTDMutex() [stdmutex.h:167]
     __rwstd::__string_ref_rep<std::allocator<char> >::~__string_ref_rep #Nvariant 1() [string.cpp]
     __rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> >::~__string_ref() [string.cpp]
     void __rwstd::__destroy<__rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> > >(__type_0*) [memory:177]
     void std::allocator_interface<std::allocator<char>,__rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> > >::destroy(__rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> >*) [memory:513]
     void std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__unLink() [string:915]
     std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string() [string:297]
     main [string.cpp:15]
     _start         [crt1.o]
* Reading 2 bytes from 0xa6d18 in the heap.
* Address 0xa6d18 is at the beginning of a freed block of 47 bytes.
* This block was allocated from:
     malloc [rtlib.o]
     c2n6Fi_Pv___1 [libCrun.so.1]
     void*operator new(unsigned) [rtlib.o]
     __rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> >*std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__getRep(unsigned,unsigned) [libCstd.so.1]
     std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string(const char*,const std::allocator<char>&) [libCstd.so.1]
     main [string.cpp:9]
     _start         [crt1.o]
* There have been 0 frees since this block was freed from:
     free [rtlib.o]
     c2k6FPv_v___1 [libCrun.so.1]
     void operator delete(void*) [rtlib.o]
     std::basic_string<char,std::char_traits<char>,std::allocator<char> >&std::basic_string<char,std::char_traits<char>,std::allocator<char> >::operator=(const std::basic_string<char,std::char_traits<char>,std::allocator<char> >&) [libCstd.so.1]
     main [string.cpp:13]
     _start         [crt1.o]
**** Purify instrumented string (pid 13888) ****
FMW: Free memory write:
* This is occurring while in:
     pthread_mutex_destroy [libthread.so.1]
     RWSTDMutex::~RWSTDMutex() [stdmutex.h:167]
     __rwstd::__string_ref_rep<std::allocator<char> >::~__string_ref_rep #Nvariant 1() [string.cpp]
     __rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> >::~__string_ref() [string.cpp]
     void __rwstd::__destroy<__rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> > >(__type_0*) [memory:177]
     void std::allocator_interface<std::allocator<char>,__rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> > >::destroy(__rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> >*) [memory:513]
     void std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__unLink() [string:915]
     std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string() [string:297]
     main [string.cpp:15]
     _start         [crt1.o]
* Writing 2 bytes to 0xa6d1e in the heap.
* Address 0xa6d1e is 6 bytes into a freed block at 0xa6d18 of 47 bytes.
* This block was allocated from:
     malloc [rtlib.o]
     c2n6Fi_Pv___1 [libCrun.so.1]
     void*operator new(unsigned) [rtlib.o]
     __rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> >*std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__getRep(unsigned,unsigned) [libCstd.so.1]
     std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string(const char*,const std::allocator<char>&) [libCstd.so.1]
     main [string.cpp:9]
     _start         [crt1.o]
* There have been 0 frees since this block was freed from:
     free [rtlib.o]
     c2k6FPv_v___1 [libCrun.so.1]
     void operator delete(void*) [rtlib.o]
     std::basic_string<char,std::char_traits<char>,std::allocator<char> >&std::basic_string<char,std::char_traits<char>,std::allocator<char> >::operator=(const std::basic_string<char,std::char_traits<char>,std::allocator<char> >&) [libCstd.so.1]
     main [string.cpp:13]
     _start         [crt1.o]
**** Purify instrumented string (pid 13888) ****
FMW: Free memory write:
* This is occurring while in:
     pthread_mutex_destroy [libthread.so.1]
     RWSTDMutex::~RWSTDMutex() [stdmutex.h:167]
     __rwstd::__string_ref_rep<std::allocator<char> >::~__string_ref_rep #Nvariant 1() [string.cpp]
     __rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> >::~__string_ref() [string.cpp]
     void __rwstd::__destroy<__rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> > >(__type_0*) [memory:177]
     void std::allocator_interface<std::allocator<char>,__rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> > >::destroy(__rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> >*) [memory:513]
     void std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__unLink() [string:915]
     std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string() [string:297]
     main [string.cpp:15]
     _start         [crt1.o]
* Writing 2 bytes to 0xa6d18 in the heap.
* Address 0xa6d18 is at the beginning of a freed block of 47 bytes.
* This block was allocated from:
     malloc [rtlib.o]
     c2n6Fi_Pv___1 [libCrun.so.1]
     void*operator new(unsigned) [rtlib.o]
     __rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> >*std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__getRep(unsigned,unsigned) [libCstd.so.1]
     std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string(const char*,const std::allocator<char>&) [libCstd.so.1]
     main [string.cpp:9]
     _start         [crt1.o]
* There have been 0 frees since this block was freed from:
     free [rtlib.o]
     c2k6FPv_v___1 [libCrun.so.1]
     void operator delete(void*) [rtlib.o]
     std::basic_string<char,std::char_traits<char>,std::allocator<char> >&std::basic_string<char,std::char_traits<char>,std::allocator<char> >::operator=(const std::basic_string<char,std::char_traits<char>,std::allocator<char> >&) [libCstd.so.1]
     main [string.cpp:13]
     _start         [crt1.o]
**** Purify instrumented string (pid 13888) ****
FMR: Free memory read:
* This is occurring while in:
     unsigned std::basic_string<char,std::char_traits<char>,std::allocator<char> >::length()const [string:1346]
     void std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__unLink() [string:916]
     std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string() [string:297]
     main [string.cpp:15]
     _start         [crt1.o]
* Reading 4 bytes from 0xa6d38 in the heap.
* Address 0xa6d38 is 32 bytes into a freed block at 0xa6d18 of 47 bytes.
* This block was allocated from:
     malloc [rtlib.o]
     c2n6Fi_Pv___1 [libCrun.so.1]
     void*operator new(unsigned) [rtlib.o]
     __rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> >*std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__getRep(unsigned,unsigned) [libCstd.so.1]
     std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string(const char*,const std::allocator<char>&) [libCstd.so.1]
     main [string.cpp:9]
     _start         [crt1.o]
* There have been 0 frees since this block was freed from:
     free [rtlib.o]
     c2k6FPv_v___1 [libCrun.so.1]
     void operator delete(void*) [rtlib.o]
     std::basic_string<char,std::char_traits<char>,std::allocator<char> >&std::basic_string<char,std::char_traits<char>,std::allocator<char> >::operator=(const std::basic_string<char,std::char_traits<char>,std::allocator<char> >&) [libCstd.so.1]
     main [string.cpp:13]
     _start         [crt1.o]
**** Purify instrumented string (pid 13888) ****
FUM: Freeing unallocated memory:
* This is occurring while in:
     free [rtlib.o]
     c2k6FPv_v___1 [libCrun.so.1]
     void operator delete(void*) [rtlib.o]
     void std::allocator<char>::deallocate(void*,unsigned) [memory:396]
     void std::allocator_interface<std::allocator<char>,char>::deallocate(char*,unsigned) [memory:493]
     void std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__unLink() [string:916]
     std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string() [string:297]
     main [string.cpp:15]
     _start         [crt1.o]
* Attempting to free block at 0xa6d18 already freed.
* This block was allocated from:
     malloc [rtlib.o]
     c2n6Fi_Pv___1 [libCrun.so.1]
     void*operator new(unsigned) [rtlib.o]
     __rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> >*std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__getRep(unsigned,unsigned) [libCstd.so.1]
     std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string(const char*,const std::allocator<char>&) [libCstd.so.1]
     main [string.cpp:9]
     _start         [crt1.o]
* There have been 1 frees since this block was freed from:
     free [rtlib.o]
     c2k6FPv_v___1 [libCrun.so.1]
     void operator delete(void*) [rtlib.o]
     std::basic_string<char,std::char_traits<char>,std::allocator<char> >&std::basic_string<char,std::char_traits<char>,std::allocator<char> >::operator=(const std::basic_string<char,std::char_traits<char>,std::allocator<char> >&) [libCstd.so.1]
     main [string.cpp:13]
     _start         [crt1.o]
**** Purify instrumented string (pid 13888) ****
Current file descriptors in use: 5
FIU: file descriptor 0: <stdin>
FIU: file descriptor 1: <stdout>
FIU: file descriptor 2: <stderr>
FIU: file descriptor 26: <reserved for Purify internal use>
FIU: file descriptor 27: <reserved for Purify internal use>
**** Purify instrumented string (pid 13888) ****
Purify: Searching for all memory leaks...
Memory leaked: 0 bytes (0%); potentially leaked: 0 bytes (0%)
Purify Heap Analysis (combining suppressed and unsuppressed blocks)
Blocks Bytes
Leaked 1 47
Potentially Leaked 3 107
In-Use 26 123707
Total Allocated 30 123861
**** Purify instrumented string (pid 13888) ****
Thread Summary : 1 threads in existence
* Thread 0 [main thread]
Stack Limit : (0xff3f0000 0xffbf0000), size = 0x800000
**** Purify instrumented string (pid 13888) ****
* Program exited with status code 0.
* 6 access errors, 6 total occurrences.
* 0 bytes leaked.
* 0 bytes potentially leaked.
* Basic memory usage (including Purify overhead):
331996 code
92532 data/bss
131072 heap (peak use)
1856 stack
* Shared library memory usage (including Purify overhead):
1456 libpure_solaris2_init.so.1 (shared code)
252 libpure_solaris2_init.so.1 (private data)
2255839 libCstd.so.1_pure_p3_c0_105022037_58_32_3592668S (shared code)
28588 libCstd.so.1_pure_p3_c0_105022037_58_32_3592668S (private data)
54269 libCrun.so.1_pure_p3_c0_105022037_58_32_1244656S (shared code)
24688 libCrun.so.1_pure_p3_c0_105022037_58_32_1244656S (private data)
139048 libm.so.1_pure_p3_c0_105022037_58_32_1289524S (shared code)
1224 libm.so.1_pure_p3_c0_105022037_58_32_1289524S (private data)
3968 libw.so.1_pure_p3_c0_105022037_58_32_1187000S (shared code)
0 libw.so.1_pure_p3_c0_105022037_58_32_1187000S (private data)
132888 libthread.so.1_pure_p3_c0_105022037_58_32_1408248S (shared code)
26192 libthread.so.1_pure_p3_c0_105022037_58_32_1408248S (private data)
1105144 libc.so.1_pure_p3_c0_105022037_58_32_1180272S (shared code)
111036 libc.so.1_pure_p3_c0_105022037_58_32_1180272S (private data)
2404 libdl.so.1_pure_p3_c0_105022037_58_32_5292S (shared code)
4 libdl.so.1_pure_p3_c0_105022037_58_32_5292S (private data)
13192 libinternal_stubs.so.1 (shared code)
932 libinternal_stubs.so.1 (private data)
31866 librt.so.1_pure_p3_c0_105022037_58_32_1269024S (shared code)
2044 librt.so.1_pure_p3_c0_105022037_58_32_1269024S (private data)
44541 libaio.so.1_pure_p3_c0_105022037_58_32_1227208S (shared code)
6104 libaio.so.1_pure_p3_c0_105022037_58_32_1227208S (private data)
14112 libc_psr.so.1_pure_p3_c0_105022037_58_32 (shared code)
0 libc_psr.so.1_pure_p3_c0_105022037_58_32 (private data)

I've run this same testcase with -xarch={generic,v8,v8a,v8plus,v8plusa,v9,v9a}, which are the only architectures I can try. Both -xarch=v8plus and -xarch=v8plusa generate code which has the issues identified above. All of the other targets are OK according to purify. What I don't understand is that the symlinks in the SUNWspro/lib/{arch} directories for all of the v8 variants point to the same libCstd in /usr/lib.
I've also upgraded to the newest version of purify from Rational:
purify -versionVersion 2003.06.00 Solaris 2
Could someone from Sun please see if they can reproduce this problem?
Thanks.

Purify-"Can't load library c:\jdk1.3.1\jre\bin\verify.dll"

I have JVM crash problem. So I tried to use purify to check the memory array boundary and other memory issues.
When I set purify to get "Memory profiling data" in "Run program" dialog, everything is ok. But if I want to get "Error and leak data", it always complained
"Can't load library c:\jdk1.3.1\jre\bin\verify.dll", because access is denied. Could not create the Java virtual machine."
I have tried JVM1.4 and JVM1.3 For JVM1.3, I am using -classic as purify requested.
Any information will be greatly appeciated. And I am dyning for the JVM crash problem. I have checked the c and JNI code and feel hard to find the problem by reading. Is there any other way or tools I can use? I have tried -Xcheck:jni, jdb. Nothing is useful. Thanks a lot.

I have JVM crash problem. So I tried to use purify to
check the memory array boundary and other memory
issues. Do you have any native code (JNI) of your own? If not, this exercise is likely to be a complete waste of time on your part, since it won't lead you to anything in your source that can be changed to fix it. It's a Java VM bug, and you'll have to deal with it in other ways.
It's entirely possible that Purify has some problems handling the JDK 1.3.1 verify.dll - probably because of some unexpected object structure or layout within it. Have you contacted Purify support?
But like I said, this is just going to be a complete waste of time on your part. Try a newer JDK (1.3.1_03 if you must stay with 1.3.1, or use the IBM 1.3 JDK, or just go to JDK 1.4.1), and see if you still run into this.

Import problems - cable?

Hello Everyone,
I'm importing from a Sony DCR-HC20 miniDV camcorder and I've been having two problems. One is similar to what I've seen in other posts (apparently without resolution). The video and audio get more and more out of sync. In the first clips it seems fine and in later ones it's quite out of sync. Thankfully, this does not happen everytime. I can't figure out why it happens and why it doesn't, though. I restart, reboot, fix permissions, anything I can think of to "purify" the environment. Sometimes it imports correctly without anything special and sometimes it gets out of sync with all of that.
The other problem is that it will sometimes import the first couple of clips and then not import (or save) any of the others. They just don't show up. I go back to those clips and then it seems to import fine (though sometimes with the audio sync problems above).
A thought just struck me. I wonder if it's the firewire cable. I have a 6ft Firewire 4 pin to 9 pin cable. It was embarrassingly cheap and now I'm wondering if it could be the source of my problems.
So, two questions. Any answers (other than the cable) to the above? And any thoughts on the cable being the problem?
Thanks in advance,
Chuck

I consistently have the problem whether importing 100 images or 3 (although I haven't tried just one). I have also tried several different cards to no avail. It seems to work fine if i turn off the "Do not import suspected duplicates" box. Or if I first import to a folder on the desktop and then import into lightroom from there with the duplicate checking on, which is what I have been doing.
Any suggestions would be greatly appreciated.

Tuxedo and Purify

I am trying to run a C++ process (instrumented with Purify) from within Tuxedo
8.0 container. Anyone done this before, versions of purify, etc? Thanks,
-Lowry

When using Purify without Tuxedo, one generally uses the "purify" command
with the arguments being the compiler line that would normally be used; i.e
"purify cc -g hello_world.c".
The key to get this to work with Tuxedo is to recognize that buildclient and
buildserver allow the CC environment variable to be used to specify an
alternate compiler to be used in place of "cc".
Anothe problem to overcome when using Purify with tuxedo is that buildserver
passes libraries to the compiler in the form "-ltux", and these are not
recognized properly or used to not be recognized properly by purify. Purify
would perfer to see the libraries in the form $TUXDIR/lib/libtux.$SUFFIX ,
where suffix may be .so, .so.71, .so.7.1, or .sl depending on your operating
system.
If you save the parts of this message after the line with dashes as an
executable shell script called purify.tux and export CC=purify.tux
you should be able to execute buildserver or buildclient as you normally
would and get an executable for Purify to use; i.e.
export CC=purify.tux
buildclient -v -f simpcl.c -o simpcl
(On NT, buildclient and buildserver use the "%TUXDIR%"\lib\libtux.lib format
for the libraries they pass to the compiler, so it should not be necessary
to edit the library names on NT as must be done on Unix.)
---------------------------- Save the rest of the file as
purify.tux -----------------------------------------------------------------
#!/usr/bin/ksh
# Front-end for "purify" to customize for TUXEDO environment
PURIFYDIR=/home/Purify # Modify this line as needed
PATH=$PATH:/home/Purify
export PATH
# Is this purify.tux, purecov.tux, or purifycov.tux?
cmdname=`basename $0`
# Run this command if purify not needed due to options
bailout="cc $@"
pcmd=""
# TUXDIR is required
if test "$TUXDIR" = ""
then
echo "$0: TUXDIR not set"
exit 1
fi
# Save space and simplify cleanup by requiring central cache directory
popts="-always-use-cache-dir=yes"
# Save output in standard place with standard name: proc.pid.plog
popts="$popts -log-file=${APPDIR:-$HOME}/%v.%p.plog"
# Report additional stack frame detail
popts="$popts -chain-length=9 -thread-stack-change=0x100000"
# Find suffix for target libraries on this platform
if test -r $TUXDIR/lib/libtux.so.[0-9][0-9]
then
# Most platforms: Solaris, SGI, etc.
suffix=`cd $TUXDIR/lib; ls libtux.so.[0-9][0-9]`
suffix=${suffix#libtux}
if test `uname -a | fgrep Sun >/dev/null; echo $?` -eq 0
then
# Solaris
# Cause executable to search for shared objects in cache
ccextra="-R
/export/home/Purify5.3/releases/purify-5.3-solaris2/cache$TUXDIR/lib"
fi
elif test -r $TUXDIR/lib/libtux.so.[0-9].[0-9]
then
# SunOS 4.x
suffix=`cd $TUXDIR/lib; ls libtux.so.[0-9].[0-9]`
suffix=${suffix#libtux}
elif test -r $TUXDIR/lib/libtux.sl
then
# HPUX
suffix=.sl
else
# Non-shared library
suffix=.a
fi
# Change clopts to explicitly reference .so files
while test $# -gt 0
do
case "$1" in
-c)
# No need for Purify if just compiling
##echo "$0: $bailout"
eval "$bailout"
exit ;;
-G)
# Purify won't work if building shared object
##echo "$0: $bailout"
eval "$bailout"
exit ;;
-lbuft)
pcmd="$pcmd $TUXDIR/lib/libbuft$suffix"
shift; continue ;;
-ldnw)
pcmd="$pcmd $TUXDIR/lib/libdnw$suffix"
shift; continue ;;
-lfml)
pcmd="$pcmd $TUXDIR/lib/libfml$suffix"
shift; continue ;;
-lfml32)
pcmd="$pcmd $TUXDIR/lib/libfml32$suffix"
shift; continue ;;
-lfs)
pcmd="$pcmd $TUXDIR/lib/libfs$suffix"
shift; continue ;;
-lgpnet)
pcmd="$pcmd $TUXDIR/lib/libgpnet$suffix"
shift; continue ;;
-lgp)
pcmd="$pcmd $TUXDIR/lib/libgp$suffix"
shift; continue ;;
-lengine)
pcmd="$pcmd $TUXDIR/lib/libengine$suffix"
shift; continue ;;
-lgp128)
pcmd="$pcmd $TUXDIR/lib/libgp128$suffix"
shift; continue ;;
-lgp40)
pcmd="$pcmd $TUXDIR/lib/libgp40$suffix"
shift; continue ;;
-lgw)
pcmd="$pcmd $TUXDIR/lib/libgw$suffix"
shift; continue ;;
-lgws)
pcmd="$pcmd $TUXDIR/lib/libgws$suffix"
shift; continue ;;
-lgwt)
pcmd="$pcmd $TUXDIR/lib/libgwt$suffix"
shift; continue ;;
-lnwi)
pcmd="$pcmd $TUXDIR/lib/libnwi$suffix"
shift; continue ;;
-lnws)
pcmd="$pcmd $TUXDIR/lib/libnws$suffix"
shift; continue ;;
-lqm)
pcmd="$pcmd $TUXDIR/lib/libqm$suffix"
shift; continue ;;
-lrms)
pcmd="$pcmd $TUXDIR/lib/librms$suffix"
shift; continue ;;
-lrpt)
pcmd="$pcmd $TUXDIR/lib/librpt$suffix"
shift; continue ;;
-lrpts)
pcmd="$pcmd $TUXDIR/lib/librpts$suffix"
shift; continue ;;
-lsql)
pcmd="$pcmd $TUXDIR/lib/libsql$suffix"
shift; continue ;;
-ltfrm)
pcmd="$pcmd $TUXDIR/lib/libtfrm$suffix"
shift; continue ;;
-ltmib)
pcmd="$pcmd $TUXDIR/lib/libtmib$suffix"
shift; continue ;;
-ltrpc)
pcmd="$pcmd $TUXDIR/lib/libtrpc$suffix"
shift; continue ;;
-ltux)
pcmd="$pcmd $TUXDIR/lib/libtux$suffix"
shift; continue ;;
-ltux2)
pcmd="$pcmd $TUXDIR/lib/libtux2$suffix"
shift; continue ;;
-lusort)
pcmd="$pcmd $TUXDIR/lib/libusort$suffix"
shift; continue ;;
-lwsc)
pcmd="$pcmd $TUXDIR/lib/libwsc$suffix"
shift; continue ;;
-lwsh)
pcmd="$pcmd $TUXDIR/lib/libwsh$suffix"
shift; continue ;;
-lgpthr)
pcmd="$pcmd $TUXDIR/lib/libgpthr$suffix"
shift; continue ;;
-lpif)
pcmd="$pcmd $TUXDIR/lib/libpif$suffix"
shift; continue ;;
-lsec)
pcmd="$pcmd $TUXDIR/lib/libsec$suffix"
shift; continue ;;
pcmd="$pcmd $1"
shift; continue ;;
esac
done
case $cmdname in
purify.tux) pcmd="purify $popts cc $ccextra $pcmd" ;;
purecov.tux) pcmd="purecov $popts cc $ccextra $pcmd" ;;
purifycov.tux) pcmd="purify $popts purecov $popts cc $ccextra $pcmd" ;;
*) echo "WARN: Command name must be purify.tux, purecov.tux, or
purifycov.tux."
echo "INFO: Assuming purify.tux"
pcmd="purify $popts cc $ccextra $pcmd" ;;
esac
echo "$0: $pcmd"
eval "$pcmd"

USING Purify for Spam - Help!!!

Hi, I just downloaded and spent an hour going through the manual and configuring apple mail and Purify settings to use that as my spam filter. Now what? I go to check my mail in apple mail and now it can't connect. Am I supposed to run Purify manually in order to get my mail? There is no mention in the manual HOW TO ACTUALLY USE IT once it is set up.
Any suggestions anyone??? Did I make a mistake with the s-ware? Other suggestions? Should I dump and use another?
Thanks.
Patrice

Hi Patrice,
I know nothing about the SW, but it looks like their Forum is fairly active...
http://www.hendricom.com/forums/index.php?s=e2f2d622c4e587a0d45ab70e9bb4cdc4&sho wforum=3
Not certain, but this can fix myriad Mail problems...
Safe Boot from the HD, (holding Shift key down at bootup), it will try to repair your Disk Directory while the spinning radian is happening, so let it go, run Disk Utility in Applications>Utilities, then highlight your drive, click on Repair Permissions, then move these folder & file to the Desktop.
Move this Folder to the Desktop...
/Users/YourUserName/Library/Caches/Mail/
Move this file to the Desktop...
/Users/YourUserName/Library/Mail/Envelope Index
Reboot.

Purify/quantify break with patch Patch-ID# 109147-14

I am not sure if this is a Sun problem or a Rational problem, in any case does anybody know of a work around? We need the patch for other issues, but now our expensive purify/quantify are completely broken!

I suspect that you require what Rational calls "Proto 38." Here's an email I got from Rational's support group:
Hi David,
Recently Purify had problems with newer Sun patches. New Forte update
compiler patches, as well as new Solaris 8 linker and libc patches caused
Purify to crash. All of them are fixed in this proto. If you are to upgrade your
Solaris patches, then please use proto 38 to avoid the crash problem.
Regards,
Yumiko
For answers to frequently asked questions please visit our Solutions
Knowledge Base at:
http://eservice.rational.com/solutions
P.S. If you need further assistance, please reply to [email protected]
with your SR# in the subject line.
We use Proto 38 and it fixed our problems. It also fixes a pre-Solaris patch bug
where purify() would die attempting to instrument the ACE toolkit [i.e. libACE.so].
Rational can provide you with the download and installation instructions.
... Dave

Purify on Sol8

Hi
I am having problem purifying on Sol 8 (SunOS jaws 5.8 Generic_108528-03 sun4u sparc SUNW,Ultra-5_1) . The problem happens while linking stage of purify and I get the following error.
Linking
ld: warning: file /usr/lib/libXm.so.4: wrong ELF class: ELFCLASS32
although the same libXm.so.4 is purified before it was being linked. Anways after the purification process is over and I try to run my purified application I get the following error
ld.so.1: p_m4testf: fatal: libXm.so.4_pure_p3_c0_000_58_64: open failed: No such file or directory
I was wondering what could the solution to the above problem
Thanks
Mohammad Tareen

Install Java 1.1.x that is included in the CD. In some cases, you must uninstall the version of Java that you have in your machine first.

A problem with threads

I am trying to implement some kind of a server listening for requests. The listener part of the app, is a daemon thread that listens for connections and instantiates a handling daemon thread once it gets some. However, my problem is that i must be able to kill the listening thread at the user's will (say via a sto button). I have done this via the Sun's proposed way, by testing a boolean flag in the loop, which is set to false when i wish to kill the thread. The problem with this thing is the following...
Once the thread starts excecuting, it will test the flag, find it true and enter the loop. At some point it will LOCK on the server socket waiting for connection. Unless some client actually connects, it will keep on listening indefinatelly whithought ever bothering to check for the flag again (no matter how many times you set the damn thing to false).
My question is this: Is there any real, non-theoretical, applied way to stop thread in java safely?
Thank you in advance,
Lefty

This was one solution from the socket programming forum, have you tried this??
public Thread MyThread extends Thread{
     boolean active = true;
     public void run(){
          ss.setSoTimeout(90);
          while (active){
               try{
                    serverSocket = ss.accept();
               catch (SocketTimeoutException ste){
               // do nothing
     // interrupt thread
     public void deactivate(){
          active = false;
          // you gotta sleep for a time longer than the
          // accept() timeout to make sure that timeout is finished.
          try{
               sleep(91);
          }catch (InterruptedException ie){
          interrupt();
}

Purify problems...?

Similar Messages

Maybe you are looking for