Closed Bug 92521 Opened 23 years ago Closed 23 years ago

Problems using Quantify with mozilla

Categories

(SeaMonkey :: Build Config, defect)

Sun
Solaris
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: jim_nance, Assigned: pavlov)

References

Details

Attachments

(1 file)

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)
For number 3 I should have said load its thread support library from the
quantify cache directory, where it of course does not exist.
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
Priority: -- → P3
Target Milestone: --- → Future
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 → ---
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).
i believe this was also fixed with newer versions of quantify
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
verified worksforme.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: