Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

-02 optimization causes NoSuchProcess exception (FreeBSD) #25

Closed
giampaolo opened this issue May 23, 2014 · 4 comments
Closed

-02 optimization causes NoSuchProcess exception (FreeBSD) #25

giampaolo opened this issue May 23, 2014 · 4 comments

Comments

@giampaolo
Copy link
Owner

From jlo...@gmail.com on February 25, 2009 15:59:47

What steps will reproduce the problem?  
1. Compile psutil with -O2 enabled
2. Run the test suite or psutil.py
3. NoSuchProcess exception thrown for *any* PID, caused by sysctl returning
ESRC for every PID passed to it. 

What is the expected output?  


What do you see instead?  
Process information should be printed as it is normally. Instead
NoSuchProcess is raised, caused by ESRCH error from sysctl regardless of PID

Original issue: http://code.google.com/p/psutil/issues/detail?id=25

@giampaolo giampaolo self-assigned this May 23, 2014
@giampaolo
Copy link
Owner Author

From jlo...@gmail.com on February 25, 2009 07:26:50

It took me *hours* to figure this out last night because the test code worked 
fine until I compiled it with distutils. I finally caught on that the only thing
different about the code (after checking it line by line 100 times) was how it 
compiled. I took the compiler output line from the distutils build and tried 
a test C app with it, and got the same "No such process" error from sysctl 
removed -O2 optimization.

For now, I fixed this by removing the -O2 flag from my Python Makefile, but 
I'd like to either patch the C code, or setup.py to override -O2 so that this 
bite someone else building on FreeBSD. Potentially this code might also affect 
or other platforms where we're compiling from C source code, not sure without 
them individually.

@giampaolo
Copy link
Owner Author

From jlo...@gmail.com on February 25, 2009 08:38:15

Fixed in r169 - caused by a int -> siz_t cast. The same cast is used in the OS 
without appearing to cause any problems but that may be worth examining for 
problems at a later date.

Status: Verified

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on March 17, 2009 08:31:20

Status: Fixed

@giampaolo
Copy link
Owner Author

From g.rodola on March 02, 2013 03:44:36

Updated csets after the SVN -> Mercurial migration: r169 == revision 

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant