505756 - getObjInfo in memory_profiler.cpp returns null on Linux

Status: RESOLVED WONTFIX

(Mozilla Labs :: Jetpack Prototype, defect, P3)

Description

[Morgan 'ARR!' Allen]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.0 Safari/532.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1) Gecko/20090721 Firefox/3.5.1 XPCOMViewer/0.9a

in function getObjectInfoAndProperties line ~55 getObjectInfo returns null.
the objNum is successfully fetch with getNamedObjects.

Reproducible: Always

Actual Results:  
getObjectInfo returns null

Expected Results:  
getObjectInfo should return JSObject

Comment 1

[Atul Varma [:atul]]

How'd you build the component?  Are you on a 64-bit version of Linux?  I've compiled it on my Ubuntu and it seems to work okay...

Comment 2

[Morgan 'ARR!' Allen]

./manage.py xpcom -t ../mozilla-1.9.1/ -o ../mozilla-1.9.1/

All the tests pass, but this is all I get from the server for /dump-win

{"meta":{},"totalBytes":0,"typeSize":{},"typeCount":{},"typeMap":{},"tabUrl":"http://www.google.de/firefox"}

Comment 3

[Matěj Cepl]

Attachment: output of ./manage.py xpcom -t ~/rpmbuild/BUILD/firefox-3.5.5/mozilla-1.9.1/ -o ~/rpmbuild/BUILD/firefox-3.5.5/mozilla-1.9.1

mcepl: actually when I try to compile hg checkout on my Fedora12/x86_64 I get
memory_profiler.cpp:70: error: extra qualification ‘ProfilerRuntime::’ on member ‘globalFunctions’ when compiling memory_profiler.cpp
ddahl: mcepl: what command did you use to compile?
mcepl: ./manage.py xpcom -t ~/rpmbuild/BUILD/firefox-3.5.5/mozilla-1.9.1/ -o ~/rpmbuild/BUILD/firefox-3.5.5/mozilla-1.9.1/
which is the directory where I just rebuild Firefox from Fedora firefox-3.5.5-1.fc12.src.rpm (Fedora 12/x86_64)
mcepl: (and yes, I would love manage.py was able to build with the standard -devel packages, but that's another matter)

Comment 4

[Christian Sonne [:cers]]

Attachment: Patch to fix problem in comment #3

(In reply to comment #3)

I was having this same problem compiling for latest trunk of firefox, and this simple patch seems to resolve the problem.

At least the xpcom command finishes without error, and all tests pass.
>Now profiling memory.
>Running COW tests.
>Successfully visited 430 objects.
>Done profiling memory.
>All tests passed!

Comment 5

[Matěj Cepl]

When applying the patch to my git repo at http://repo.or.cz/w/jetpack.git (sorry, I am from Red Hat and it is all git here, and I am lazy to learn hg), I can build jetpack pretty well, but in the end ./manage.py xpcom fails:

gmake[1]: Leaving directory `/home/matej/rpmbuild/BUILD/firefox-3.5.5/mozilla-1.9.1/browser/components/jetpack'


Captured Task Output:
---------------------

---> pavement.xpcom
Traceback (most recent call last):
  File "/home/matej/archiv/2009/projekty/jetpack/python-modules/paver/tasks.py", line 164, in _run_task
    return do_task()
  File "/home/matej/archiv/2009/projekty/jetpack/python-modules/paver/tasks.py", line 161, in do_task
    return func(**kw)
  File "/home/matej/archiv/2009/projekty/jetpack/manage.py", line 623, in xpcom
    xpcom_info.components_dir)
  File "/usr/lib64/python2.6/shutil.py", line 88, in copy
    copyfile(src, dst)
  File "/usr/lib64/python2.6/shutil.py", line 53, in copyfile
    fdst = open(dst, 'wb')
IOError: [Errno 13] Permission denied: '/usr/lib64/xulrunner-sdk-1.9.1/bin/components/libjetpack.so'

I guess the part of the problem is that I am using firefox build  from Fedora Firefox package, which is based on separate xulrunner. I understand I could probably avoid the problem by using firefox build from the upstream tarball, but I would really like to get to the stage where jetpack could be packaged for Fedora. Is it possible to persuade jetpack to build in a separate read-write build directory?

Otherwise I think this bug could be fixed by this patch.

Comment 6

[Matěj Cepl]

When I have built complete firefox without xulrunner, build of jetpack proceeds without a problem. Tests which then go on during build went on succesfully. When running unit tests in about:jetpack, I still get 9 tests failed.

Comment 7

[Daniel Buchner [:dbuc]]

We will be monitoring all these issues after the rebooted Jetpack code base is released in the first week of March to ensure their causes are not duplicated. Many of the bugs/issues with the prototype version of Jetpack will be made irrelevant given the structure of the new SDK.