If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

runtests.py is out to get bz (path-to-libraries problem)

NEW
Unassigned

Status

Testing
Mochitest
10 years ago
9 years ago

People

(Reporter: shaver, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

17:03 <@bz> when I attach with gdb to the firefox process it starts...
17:03 <@bz> gdb can't find libxcom_core.so
17:04 <@bz> or rather ./../../../dist/etc/libxcom_core.so

17:04 < shaver> shouldn't gdb be able to find that?
17:04 < shaver> I guess not if the process chdir'd
17:04 <@bz> shaver: depends on where it's thinking it needs to start looking 
            from...
17:05 <@bz> fwiw, with runtests.pl, the path is

17:05 <@bz>  /home/bzbarsky/mozilla/vanilla/obj-firefox/_tests/testing/mochitest//../../../dist/bin/libxpcom_core.so
17:05 <@bz> which is eminently findable even by gdb
17:06 <@bz> fwiw, I just followed the directions in 
            http://developer.mozilla.org/en/docs/Chrome_tests for running a 
            single test using --test-path
Component: Testing → Mochitest
Product: Core → Testing
QA Contact: testing → mochitest
Version: Trunk → unspecified
This is probably less of a problem with bug 480279, but I haven't actually tried to reproduce, so I'm not sure of the full scope.
I have no idea, since --debugger doesn't work over here.
Though note that this bug was seen on Linux and now I'm on Mac; on Mac I can actually attach with gdb after starting the mochitest process (so this bug is worksforme on mac).
OS: Mac OS X → Linux
You need to log in before you can comment on or make changes to this bug.