92521 - Problems using Quantify with mozilla

Status: VERIFIED WORKSFORME

(SeaMonkey :: Build Config, defect)

Description

[jim_nance]

Today I did some quantify runs and I had to work around several quantify bugs in
order to make things work.  These are bugs in quantify, not mozilla, but
quantify is a useful product, and I would like someone to bring up these issues
with Rational.  I dont think that I am a good person to do that, but I hope that
there is someone at mozilla.org who is.

I was building 32 bit code under Solaris 7 with the Sun Workshop 6.0 compiler
with (I think) the latest updates.  The problems I noticed were:

1) If a static build of mozilla is instrumented with either purify or quantify
   the resulting executable never brings up a window.  It just sits there.

2) When running/instrumenting optimized mozilla binaries, the executable will
   crash.  If the crash is caught in dbx and the file mozilla crashed in is
   rebuilt w/o optimization, the crash goes away.  I did not write down the
   file names that require this treatment, but there were 2 of them.

3) Running the instrumented binary under the dbx from Workshop 6.0 causes dbx to
   crash.  The dbx from Workshop 5.0 works.  The error messages printed by dbx
   before it crashes seem to indicate that it is trying to load its thread
   support:

Reading libc_psr.so.1_pure_q800_520_57_32
detected a multithreaded program
dbx: warning: cannot dlopen standard
"/bigdisk/jnance/mbuild/dist/pcache/usr/lib/sparcv9/libthread_db.so.1" --
ld.so.1: /tools/SC6.0/bin/../WS6U1/bin/sparcv9/dbx: fatal:
/bigdisk/jnance/mbuild/dist/pcache/usr/lib/sparcv9/libthread_db.so.1: open
failed: No such file or directory
dbx: warning: thread related commands will not be available
dbx: warning: see `help lwp', `help lwps' and `help where'
(/tools/SC6.0/bin/../WS6U1/bin/sparcv9/dbx) run
Running: mozilla-bin.quantify 
(process id 25640)
detected a multithreaded program

dbx: internal error: signal SIGSEGV (no mapping at the fault address)
dbx's coredump will appear in /tmp
Abort (core dumped)

Comment 1

[jim_nance]

For number 3 I should have said load its thread support library from the
quantify cache directory, where it of course does not exist.

Comment 2

[jim_nance]

Attachment: Script used to build quantified mozilla

Comment 3

[timeless]

I've actually seen (3) before, I was probably trying to use purify or quantify, 
but i'm not certain.

cc'd some sun people and some rational people, hopefully they can help.
Changing platform to Sun to indicate Sparc (solaris x86 exists ...)
I'm adding this to my personal tracker bug.
Moving to Build Config to save Asa from bugmail.

Comment 4

[cls]

Are you using the latest version of Quantify?  Afaik, only the latest one
(released last month) supports WS6.  Reassigning to pavlov as he's the only one
I know of who has run quantify/purify on solaris.

Comment 5

[Stuart Parmenter]

We ran into this.  There is a note about this somewhere on rational's website.  
You basically have to create a symlink in the cache directory to the real file 
(if i remember correctly).

Comment 6

[Stuart Parmenter]

i believe this was also fixed with newer versions of quantify

Comment 7

[Jon Granrose]

verified worksforme.