Problems using Quantify with mozilla

VERIFIED WORKSFORME

Status

VERIFIED WORKSFORME
17 years ago
14 years ago

People

(Reporter: jim_nance, Assigned: pavlov)

Tracking

Trunk
Sun
Solaris

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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)
(Reporter)

Comment 1

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

Comment 2

17 years ago
Created attachment 43763 [details]
Script used to build quantified mozilla

Comment 3

17 years ago
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.
Assignee: asa → cls
Blocks: 79119
Component: Browser-General → Build Config
QA Contact: doronr → granrose
Hardware: PC → Sun

Updated

17 years ago
Priority: -- → P3
Target Milestone: --- → Future

Comment 4

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


Assignee: cls → pavlov
Priority: P3 → --
Target Milestone: Future → ---
(Assignee)

Comment 5

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

Comment 6

17 years ago
i believe this was also fixed with newer versions of quantify
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 7

17 years ago
verified worksforme.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.