Closed Bug 930808 Opened 11 years ago Closed 10 years ago

RuntimeWarning: couldn't determine platform's TOTAL_PHYMEM

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla37

People

(Reporter: jonasfj, Assigned: gps)

References

Details

Attachments

(4 files, 1 obsolete file)

Fix for newer psutil
1.44 KB, patch
Details | Diff | Splinter Review
Error while running mach build
1.24 KB, text/plain
Details
MozReview Request: Bug 930808 - Upgrade virtualenv to 12.0.2
39 bytes, text/x-review-board-request
glandium
: review+
Details
MozReview Request: Bug 930808 - Upgrade to psutil 2.1.3
39 bytes, text/x-review-board-request
glandium
: review+
Details 
So think might be a duplicate of bug 881700 (or at least related to), but on debian wheezy, mach broke with an update today (it was working yesterday).

> python/psutil/psutil/_pslinux.py:108: RuntimeWarning: couldn't determine platform's TOTAL_PHYMEM
>   warnings.warn("couldn't determine platform's TOTAL_PHYMEM", RuntimeWarning)

Followed by an attribute error:
> AttributeError: 'module' object has no attribute 'get_sysinfo'
> 
>   File "/home/jonasfj/Mozilla/startup-io-telemetry/mc2/python/mozbuild/mozbuild/mach_commands.py", line 306, in build
>     monitor.init(warnings_path)
>   File "/home/jonasfj/Mozilla/startup-io-telemetry/mc2/python/mozbuild/mozbuild/controller/building.py", line 278, in init
>     self.resources = SystemResourceMonitor(poll_interval=1.0)
>   File "/home/jonasfj/Mozilla/startup-io-telemetry/mc2/testing/mozbase/mozsystemmonitor/mozsystemmonitor/resourcemonitor.py", line 180, in __init__
>     virt = psutil.virtual_memory()
>   File "/home/jonasfj/Mozilla/startup-io-telemetry/mc2/python/psutil/psutil/__init__.py", line 1170, in virtual_memory
>     return _psplatform.virtual_memory()
>   File "/home/jonasfj/Mozilla/startup-io-telemetry/mc2/python/psutil/psutil/_pslinux.py", line 143, in virtual_memory
>     total, free, buffers, shared, _, _ = _psutil_linux.get_sysinfo()


$ sudo pip install psutil

Fixed the problem, but it would generally be smarter to try/catch `psutil.virtual_memory()` or anything that touches `psutil`.
I can't imagine that these are strictly critical to `mach`, we should just have sane defaults, and give severe warning if
resource detection/monitoring doesn't work.
Got the same error on Ubuntu 13.10...

Will try sudo pip install psutil to see if it helps...

rcampbell@CampbellFamilyMain:~/Source/firefox$ ./mach build/home/rcampbell/Source/firefox/python/psutil/psutil/_pslinux.py:108: RuntimeWarning: couldn't determine platform's TOTAL_PHYMEM
  warnings.warn("couldn't determine platform's TOTAL_PHYMEM", RuntimeWarning)
Error running mach:

    ['build']

The error occurred in code that was called by the mach command. This is either
a bug in the called code itself or in the way that mach is calling it.

You should consider filing a bug for this issue.

If filing a bug, please include the full output of mach, including this error
message.

The details of the failure are as follows:

AttributeError: 'module' object has no attribute 'get_sysinfo'

  File "/home/rcampbell/Source/firefox/python/mozbuild/mozbuild/mach_commands.py", line 306, in build
    monitor.init(warnings_path)
  File "/home/rcampbell/Source/firefox/python/mozbuild/mozbuild/controller/building.py", line 278, in init
    self.resources = SystemResourceMonitor(poll_interval=1.0)
  File "/home/rcampbell/Source/firefox/testing/mozbase/mozsystemmonitor/mozsystemmonitor/resourcemonitor.py", line 180, in __init__
    virt = psutil.virtual_memory()
  File "/home/rcampbell/Source/firefox/python/psutil/psutil/__init__.py", line 1170, in virtual_memory
    return _psplatform.virtual_memory()
  File "/home/rcampbell/Source/firefox/python/psutil/psutil/_pslinux.py", line 143, in virtual_memory
    total, free, buffers, shared, _, _ = _psutil_linux.get_sysinfo()
Workaround "sudo pip install psutil" confirmed to work on my system (Ubuntu 13.10 amd64).
I had the same problem on Ubuntu 12.04. This is due to the system's python-psutil package being too old (0.4) compared with what's in mozilla-central (1.0).

I backported psutil 1.2 (from Debian unstable) to Precise in my PPA: https://launchpad.net/~fmarier/+archive/ppa
I just ran into this today caused by the opposite: Having psutil 2.0 installed. The version of psutil in the tree still tries to pull in bits from the installed system -- but just removing the system install, or running in a clean virtualenv, works fine.

It also only seems to happen when building a fresh tree -- whatever *.pyc-and-friends cruft ends up in the build directory seems to prevent it from happening on subsequent builds.
Hello ,

I have following System :
Ubuntu 12.04 64 bit 
Have Python Python 2.7.3 installed.

But i am getting Error :
Mozilla/src$ ./mach build
/home/ubbvand2/Himanshu/Mozilla/src/python/psutil/psutil/_pslinux.py:108: RuntimeWarning: couldn't determine platform's TOTAL_PHYMEM
  warnings.warn("couldn't determine platform's TOTAL_PHYMEM", RuntimeWarning)
Error running mach:

    ['build']

The error occurred in code that was called by the mach command. This is either
a bug in the called code itself or in the way that mach is calling it.

You should consider filing a bug for this issue.

If filing a bug, please include the full output of mach, including this error
message.

The details of the failure are as follows:

AttributeError: 'module' object has no attribute 'get_sysinfo'

  File "/home/ubbvand2/Himanshu/Mozilla/src/python/mozbuild/mozbuild/mach_commands.py", line 287, in build
    monitor.init(warnings_path)
  File "/home/ubbvand2/Himanshu/Mozilla/src/python/mozbuild/mozbuild/controller/building.py", line 161, in init
    self.resources = SystemResourceMonitor(poll_interval=1.0)
  File "/home/ubbvand2/Himanshu/Mozilla/src/testing/mozbase/mozsystemmonitor/mozsystemmonitor/resourcemonitor.py", line 180, in __init__
    virt = psutil.virtual_memory()
  File "/home/ubbvand2/Himanshu/Mozilla/src/python/psutil/psutil/__init__.py", line 1170, in virtual_memory
    return _psplatform.virtual_memory()
  File "/home/ubbvand2/Himanshu/Mozilla/src/python/psutil/psutil/_pslinux.py", line 143, in virtual_memory
    total, free, buffers, shared, _, _ = _psutil_linux.get_sysinfo()

Does any one known to resolved it?
I try below thing as well:
sudo pip install --upgrade psutil

But no luck to get it worked it.
Himanshu: have you tried upgrading the psutil package as described in comment #3? I'm running 12.04 (amd64) and that solved it for me.
As I noted this can also be caused by your version of psutil being newer than mozilla-central's. As more people get psutil 2.0 this is going to become annoying :-/
@Francois ,

Yes i follow Comment 3 to install psutil package.

And i print my package version as well like below .

dpkg-query --show python-psutil
python-psutil	1.2.1-1~ppa1

But Still i am getting same Error in my Comment 5.

@John Schoenick My version of psutil is 1.2.1 but that does seem to not Working yet.

My System Info:

Ubuntu 12.04 64 bit 

Processor : Intel® Core™ i3-2120 CPU @ 3.30GHz × 4
If any one have same issue like me then they can follow step like below .

1)sudo apt-get --purge remove python-psutil

2)sudo apt-get --purge autoremove

3)sudo apt-get update

4)Follow step from this link to install psutil-1.0.1.tar.gz  https://bugzilla.mozilla.org/show_bug.cgi?id=908296

5) Unzip it and sudo -s

6)cd psutil
python setup.py install
python -c "import psutil; psutil.virtual_memory()"

make sure when you are running above two command you have root permission else it may be fail due to permission issue .

8) sudo -s

9)Mozilla /src/./mach build 

it is now working for me.
Hmm, I just tried to reproduce this a vagrant box with wheezy. I even installed python-psutil, but no luck. I can't seem to reproduce this. Perhaps it was fixed with bug 907902.

If you're still experiencing this, maybe deriving a reliable way to reproduce this bug would be a first step to resolving this. I imagine a Vagrantfile with a list of commands to execute would be useful for anybody looking into fixing this.

Presumably, this is caused by improper isolation of the python packages by mach could be the issue.
Apparently it reimplement it's own virtualenv, see:
http://dxr.mozilla.org/mozilla-central/source/build/docs/python.rst
(In reply to Jonas Finnemann Jensen (:jonasfj) from comment #10)
> Hmm, I just tried to reproduce this a vagrant box with wheezy. I even
> installed python-psutil, but no luck. I can't seem to reproduce this.
> Perhaps it was fixed with bug 907902.
> 
> If you're still experiencing this, maybe deriving a reliable way to
> reproduce this bug would be a first step to resolving this. I imagine a
> Vagrantfile with a list of commands to execute would be useful for anybody
> looking into fixing this.
> 
> Presumably, this is caused by improper isolation of the python packages by
> mach could be the issue.
> Apparently it reimplement it's own virtualenv, see:
> http://dxr.mozilla.org/mozilla-central/source/build/docs/python.rst

Note that the cached *.pyc files or other cruft that gets left behind in the the build directory seems to prevent this, it is only on a "fresh" build that it occurs:

> # Purge everything, even ignored stuff
> hg purge --all
> # or git clean -xfd
> rm -rf objdir
>
> pip install psutil==2.1.0
> ./mach build
I had the same problem in Arch linux with python2-psutil v2.1.0-1 installed. I didn't have a build in the system before so it was clean. After trying everything you mentioned here the only solution was to remove the psutil package from the system. I will try to repeat that in a VM within the next couple of days to confirm that.
Unfortunately I couldn't reproduce the bug. I've used a VM with an Arch linux derivative in which I could build successfully. I then installed psutil v2.1.0 via the package manager, clobbered the build and successfully built again.
I have this issue with Debian Jessie (currently "testing").  The default install of python-psutil is 2.1.1-1+b1.  This is with a fresh "hg clone" of mozilla-central today which resulted in a tip of 88adcf8fef83.

I attempted to downgrade to 0.5.1-1 from stable, with the same effect.

I attempted the "sudo pip install psutil" which required the addition of the "--upgrade" flag: "sudo pip install --upgrade psutil" which downloaded and installed psutil-2.1.3, with the same effect.

I attempted "sudo pip install psutil==2.1.0", with the same effect.

I attempted "sudo pip install psutil==1.0.0", and the build succeeds.
(In reply to K Everets from comment #15)
> I have this issue with Debian Jessie (currently "testing").  The default
> install of python-psutil is 2.1.1-1+b1.  This is with a fresh "hg clone" of
> mozilla-central today which resulted in a tip of 88adcf8fef83.
> 
> I attempted to downgrade to 0.5.1-1 from stable, with the same effect.
> 
> I attempted the "sudo pip install psutil" which required the addition of the
> "--upgrade" flag: "sudo pip install --upgrade psutil" which downloaded and
> installed psutil-2.1.3, with the same effect.
> 
> I attempted "sudo pip install psutil==2.1.0", with the same effect.
> 
> I attempted "sudo pip install psutil==1.0.0", and the build succeeds.

I can confirm this on updated Archlinux. The pacman installed version of psutil was 2.1.3-1, using pip to downgrade to 1.0.0 fixed the error.
I can confirm that this happens on the updated Ubuntu 14.10.
K Everets' fix of downgrading psutil to 1.0.0 via pip works for me.
Another data-point from me:

- Ubuntu 12.04
- First time building fennec
- "sudo pip install psutil==1.0.0" worked (thanks, K Everets)
I also ran into this problem on Debian sid.  Assuming `./mach bootstrap` would fix it, I ran into another unrelated error reported in bug 1111256.
This is a fix for the new psutil. It's the first time I submit any patch to Mozilla, so please be careful. The newer versions of psutil rename get_sysinfo() to linux_sysinfo(). The returned list is the same. I'm following the rule of coding for the latest API and backporting to older versions (not sure it's in force for Mozilla, but it has worked for me greatly in other projects). So first we try to import linux_sysinfo. If it fails, we import get_sysinfo and alias it as linux_sysinfo. The callers use linux_sysinfo.

I'm puzzled why doesn't the build system force using the psutil implementation bundled with the code? It makes bundling quite pointless.
The patch is unacceptable because we don't want to get in the business of patching 3rd party code unless it can be avoided.

There are a long-standing, unresolved issues with how the build system builds binary Python packages and does sys.path muckery. Enough people have encountered this problem lately. I think I may spend time today fixing this...
Assignee: nobody → gps
Status: NEW → ASSIGNED
Component: mach → Build Config
Attached file MozReview Request: bz://930808/gps (obsolete) — 

        Attachment #8540843 -
        Flags: review?(mh+mozilla)

    
    

    
  
/r/1681 - Bug 930808 - Upgrade virtualenv to 12.0.2
/r/1683 - Bug 930808 - Upgrade to psutil 2.1.3

Pull down these commits:

hg pull review -r 90b02e514e5dd1249d97d83223ef8fcf20c9da94

    
    

    
  
I have a patch that switches the virtualenv construction to use pip (instead of setuptools/distutils) for installing psutil. Unfortunately, this breaks resource monitoring in the build because all our Python is expecting things to be in the source directory and the interaction between mach and client.mk is... complicated. I may submit a few more patches if I get it to work. Otherwise, upgrading the in-tree psutil to 2.1.3 should be sufficient for fixing this issue (I think?).

        Attachment #8540843 -
        Flags: review?(mh+mozilla) → review+

    
    

    
  
https://reviewboard.mozilla.org/r/1679/#review1083

Not that it matters much, but you also removed .travis.yml from the psutil tarball, which is not mentioned in the commit message.

    
    

    
  
https://reviewboard.mozilla.org/r/1679/#review1087

Hmmm. I guess my `mv *` didn't move dotfiles. Not that it matters. I'll update the commit message.

    
    

    
  
Backed out psutil in https://hg.mozilla.org/integration/fx-team/rev/fd2a21b856ee until you figure out what you're going to do about needing a clobberer-clobber rather than a CLOBBER-clobber to not blow up OS X.

    
    

    
  
Tonight has reminded me how awful the Python/virtualenv situation in the build system is.

Upgrading psutil resulted in |make check| failures in runxpcshelltests.py because |import psutil| was raising an AttributeError because a psutil .py file was attempted to access an attribute set by a new version of a psutil C extension. Unfortunately, the psutil C extension wasn't getting built on OS X. But it did on Windows and Linux. We got an old version of the C extension and hit the AttributeError. Strange. It appears we're running |python setup.py build_ext| but it no-ops on OS X. I suspect a setuptools/distutils bug. 

We ran into this previously with 7be399d00f9a (bug 908296). Our solution there was to catch more exceptions importing psutil (Exception not ImportError) and tell developers to delete the psutil build files from python/psutil if they wanted to get psutil back. It was ugly. But it worked.

We did something here to patch runxpcshelltests.py. That made the OS X |make check| failure go away.

The backout of psutil due to OS X bustage made Linux builds go red because package downgrades aren't handled by our virtualenv code. We essentially have the same problem in reverse.

In both cases, clobbering the source directory (a proxy for "delete vcs ignored files from python/psutil") is a sufficient workaround.

Long term, we need to stop writing Python files into the source directory and we need proper dependencies around things installed in the virtualenv. Doing this is somewhat complicated because of the various ways Python can get called throughout the build system. If it were an easy problem, it would be solved already. It's one of those medium-sized fruits that is tempting to address, but doesn't really have enough upside to warrant investing in. Solving it likely involves breaking a lot of things with sub-par test coverage and annoys people even more than the pain of upgrading psutil. I hate these types of problems :/
Blocks: 1115538

    
  
Blocks: 1115968

    
    

    
  
(In reply to Gregory Szorc [:gps] from comment #30)
> Tonight has reminded me how awful the Python/virtualenv situation in the
> build system is.
> 
> Upgrading psutil resulted in |make check| failures in runxpcshelltests.py
> because |import psutil| was raising an AttributeError because a psutil .py
> file was attempted to access an attribute set by a new version of a psutil C
> extension. Unfortunately, the psutil C extension wasn't getting built on OS
> X. But it did on Windows and Linux. We got an old version of the C extension
> and hit the AttributeError. Strange. It appears we're running |python
> setup.py build_ext| but it no-ops on OS X. I suspect a setuptools/distutils
> bug. 
> 
> We ran into this previously with 7be399d00f9a (bug 908296). Our solution
> there was to catch more exceptions importing psutil (Exception not
> ImportError) and tell developers to delete the psutil build files from
> python/psutil if they wanted to get psutil back. It was ugly. But it worked.
> 
> We did something here to patch runxpcshelltests.py. That made the OS X |make
> check| failure go away.
> 
> The backout of psutil due to OS X bustage made Linux builds go red because
> package downgrades aren't handled by our virtualenv code. We essentially
> have the same problem in reverse.
> 
> In both cases, clobbering the source directory (a proxy for "delete vcs
> ignored files from python/psutil") is a sufficient workaround.
> 
> Long term, we need to stop writing Python files into the source directory
> and we need proper dependencies around things installed in the virtualenv.
> Doing this is somewhat complicated because of the various ways Python can
> get called throughout the build system. If it were an easy problem, it would
> be solved already. It's one of those medium-sized fruits that is tempting to
> address, but doesn't really have enough upside to warrant investing in.
> Solving it likely involves breaking a lot of things with sub-par test
> coverage and annoys people even more than the pain of upgrading psutil. I
> hate these types of problems :/

Gregory, all your solutions never worked on my system. Indeed, what happens is that I already have psutil installed from my distribution (ubuntu 14.04), which is 1.2.1-1ubuntu2.

When the package is installed, it conflicts somehow. I have to remove the package from my system to be able to build Gecko ... But I have other softwares that are depending on this package :(.
Flags: needinfo?(gps)

    
    

    
  


  
I get an error while running mach build; output attached. I tried running "sudo pip install psutil==1.0.0" and that didn't help. Neither did "sudo pip install --upgrade psutil" which upgraded it to 3.1.2. I tried "sudo pip uninstall psutil" and various variations thereof but it doesn't seem to find anything to uninstall which is silly. Anyway I just backed out your three patches locally and got back to work.

    
    

    
  
I also ran into this problem (I'm on arch linux). Tested everything with the psutil version of my system, but no luck.

It appears that running:

mv /home/jp/dev/mozilla-central/python/psutil /home/jp/dev/mozilla-central/python/psutil2

with the standard psutil on arch (pacman -S python2-psutil) did the trick (I am now able to run ./mach commands).

So I suppose there is a problem of PYTHONPATH somewhere, because the psutil of my system is only used if there is none found in {mozilla-central}/python/.

Note the content of my .mozconfig is:

mk_add_options PYTHON=/usr/bin/python2

    
    

    
  
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #33)
> Created attachment 8541981 [details]
> Error while running mach build
> 
> I get an error while running mach build; output attached. I tried running
> "sudo pip install psutil==1.0.0" and that didn't help. Neither did "sudo pip
> install --upgrade psutil" which upgraded it to 3.1.2. I tried "sudo pip
> uninstall psutil" and various variations thereof but it doesn't seem to find
> anything to uninstall which is silly.

|sudo pip| == "you are doing it wrong". Please don't use sudo with Python packaging. Please read http://gregoryszorc.com/blog/2014/07/15/python-packaging-do%27s-and-don%27ts/

    
    

    
  
For people encountering *new* errors on upgrade, removing python/psutil/*.so or python/psutil/*.pyd (on Windows) should work around the problem.

I'll open a new bug to track the Ubuntu / system psutil foo.
Flags: needinfo?(gps)

    
  
Blocks: 1116194

    
    

    
  

        Attachment #8540843 -
        Attachment is obsolete: true

        Attachment #8618050 -
        Flags: review+

        Attachment #8618051 -
        Flags: review+

    
  
Product: Core → Firefox Build System

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: