Last Comment Bug 686097 - dist/bin/xpcshell: symbol lookup error: dist/bin/xpcshell: undefined symbol: JSVAL_NULL
: dist/bin/xpcshell: symbol lookup error: dist/bin/xpcshell: undefined symbol: ...
Status: NEW
: regression
Product: Core
Classification: Components
Component: XPConnect (show other bugs)
: Trunk
: x86_64 Linux
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-09 23:27 PDT by Alex Vincent [:WeirdAl]
Modified: 2011-12-13 07:51 PST (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
mozconfig (565 bytes, text/plain)
2011-09-09 23:27 PDT, Alex Vincent [:WeirdAl]
no flags Details
ldd -d -r dist/bin/xpcshell (4.64 KB, text/plain)
2011-09-09 23:28 PDT, Alex Vincent [:WeirdAl]
no flags Details

Description Alex Vincent [:WeirdAl] 2011-09-09 23:27:27 PDT
Created attachment 559662 [details]
mozconfig

For some reason, using this mozconfig on my Fedora Linux machine, xpcshell will not start.  Instead, I get the error in the summary.

This does NOT happen with Aurora code.  So it's a relatively recent regression.
Comment 1 Alex Vincent [:WeirdAl] 2011-09-09 23:28:59 PDT
Created attachment 559663 [details]
ldd -d -r dist/bin/xpcshell
Comment 2 Alex Vincent [:WeirdAl] 2011-09-10 15:18:47 PDT
<sfink> does it magically start working if you set LD_LIBRARY_PATH to .../dist/bin before running?

Yes, it does.

Another note:  this didn't affect me on my Windows or Mac systems.
Comment 3 Mike Hommey [:glandium] 2011-10-04 04:27:34 PDT
xpcshell is not supposed to run without run-mozilla.sh, which sets LD_LIBRARY_PATH appropriately. I don't think anything changed in that regard. Are you sure you were actually using the libs from dist/bin before?
Comment 4 Martin Stránský 2011-10-04 04:33:04 PDT
It fails as a part of make install (when building xulrunner as rpm package). set up LD_LIBRARY_PATH does not help me...investigating.
Comment 5 Martin Stránský 2011-10-04 04:47:09 PDT
It fails because xpcshell has a rpath to /usr/lib/xulrunner-2 and /usr/lib64/xulrunner-2/libmozjs.so there does not contain JSVAL_NULL. 

So the new xpcshell still runs with old (installed) libraries when system xulrunner is installed.
Comment 6 Mike Hommey [:glandium] 2011-10-04 05:05:18 PDT
(In reply to Martin Stránský from comment #5)
> It fails because xpcshell has a rpath to /usr/lib/xulrunner-2 and
> /usr/lib64/xulrunner-2/libmozjs.so there does not contain JSVAL_NULL. 
> 
> So the new xpcshell still runs with old (installed) libraries when system
> xulrunner is installed.

For you it fails because of that. But we don't set an rpath in our build system. So Alex's problem is different (though the cause is similar: his build must be using some other libmozjs.so)
Comment 7 Martin Stránský 2011-10-04 05:17:36 PDT
(In reply to Mike Hommey [:glandium] from comment #6)
> For you it fails because of that. But we don't set an rpath in our build
> system. So Alex's problem is different (though the cause is similar: his
> build must be using some other libmozjs.so)

Alex says he runs Fedora like me so I guess it's the same problem ;-)
Comment 8 Alex Vincent [:WeirdAl] 2011-10-04 08:38:34 PDT
FWIW, I run 64-bit Fedora, which for all I know may be a factor here.
Comment 9 Martin Stránský 2011-10-05 01:31:23 PDT
libmozjs.so => /usr/lib64/xulrunner-2/libmozjs.so (0x00007f0e5d710000)

It looks like your xpcshell has a rpath to /usr/lib64/xulrunner-2 which is a system-wide xulrunner on Fedora. In Fedora xulrunner rpm it's caused by 

export LDFLAGS="-Wl,-rpath,%{mozappdir}"

line in xulrunner.spec (or firefox.spec).

btw. the "regression" here is caused by new symbols in libmozjs.so, which are not present in old (system-wide) libmozjs.so.
Comment 10 Takanori MATSUURA 2011-10-05 01:43:53 PDT
Is this something like bug 686434?
Comment 11 Martin Stránský 2011-10-05 01:46:13 PDT
Yes, seems so, although Alex haven't told us how he builds the code.
Comment 12 Alex Vincent [:WeirdAl] 2011-10-05 07:57:35 PDT
I don't do anything special.  I attached my mozconfig earlier.  Basically, what I do is the following:

export MOZCONFIG=(path to mozconfig)
cat $MOZCONFIG # So I can be sure I got it right
cd trunk/mozilla
hg pull -u
make -f client.mk configure
cd ../fx-debug # in this case; I usually build optimized instead
make -j40 -s
dist/bin/xpcshell
Comment 13 Alex Vincent [:WeirdAl] 2011-10-05 07:58:53 PDT
Also, I typically blow away my objdir every time, so it's a clobber build, not incremental.
Comment 14 Mike Hommey [:glandium] 2011-10-06 15:11:35 PDT
I hear that fedora's xulrunner package ships a /etc/ld.so.conf.d/xulrunner-64.conf file that makes ld.so search in /usr/lib64/xulrunner-1.9.2 for libs... that would explain your problem. In all cases, xpcshell should be run through run-mozilla.sh or some other script that sets the environment correctly.
Comment 15 Takanori MATSUURA 2011-10-06 17:31:12 PDT
During the build stage, newly generated binaries should search shared objects under dist/ first.

BTW, does "-j40" works fine?
I have never tested -j40. And I have never got this kind of error with -j2 or -j4 on Fedora.
Comment 16 Mike Hommey [:glandium] 2011-10-06 23:22:27 PDT
(In reply to Takanori MATSUURA from comment #15)
> During the build stage, newly generated binaries should search shared
> objects under dist/ first.

All calls to binaries during the build should already be properly wrapped. But there could be a few missing, I don't know.
Comment 17 Martin Stránský 2011-10-06 23:31:04 PDT
(In reply to Mike Hommey [:glandium] from comment #14)
> I hear that fedora's xulrunner package ships a
> /etc/ld.so.conf.d/xulrunner-64.conf file that makes ld.so search in
> /usr/lib64/xulrunner-1.9.2 for libs... that would explain your problem. In
> all cases, xpcshell should be run through run-mozilla.sh or some other
> script that sets the environment correctly.

Yes, that's correct, we ship that file on Fedora, mostly for historical reasons (gtkmozembed apps).

Note You need to log in before you can comment on or make changes to this bug.