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
Component: Browser-General → Build Config
QA Contact: doronr → granrose
Hardware: PC → Sun
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
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.