mmass 5.0.1 and python 2.7.3-1.fc16

[Farsight]

Hi folks,

Having installed the "mmass" mass spectrometry software via the mmass repo (available here), I am now trying to launch the software. Unfortunately, I am currently greeted by the following message: "A problem in the python-2.7.3-1 package was detected".

I have performed software updates and believe I am running the most up-to-date stable python release (2.7.3-1.fc16).

Is there a way by which I can perhaps repair or reinstall python so that this software can work?

Note: I've downloaded and installed the same software using Ubuntu 12.04 without issue, so I guess it's something to do with my Fedora installation as opposed to mmass itself.

All the best,
Farsight.

[tashirosgt]

I think you'd get better advice about this if you ask in the programming section of the forum.

I'm not a python expert, but since there is a PDF on the web called "Python Package Management Sucks", the thought occurs that your problem might have to do with the files and enviromental variables that define where Python looks for modules. Section 6.1.2 and 6.4 of http://docs.python.org/tutorial/modules.html describe this.

From the remark in section 6.1.2 that PYTHONPATH "has the same syntax" as the shell variable PATH, I wonder if you can use the command line command:

echo $PYTHONPATH

to see the value of this path. You could compare it on Ubuntu vs Fedora.

That' s just an uneducated guess.

Have you tried running some simple Python program other than mmass?

[george_toolan]

Try

yum install python3-numpy

[Farsight]

Hi folks,

I've tried both options and had no success. In Ubuntu 12.04 and Fedora 16, the command echo $PYTHONPATH just returns a blank line. I've yet to try a simple python application - I'm not really sure what would be a suitable application to use for testing. Any recommendations?

Having installed the python3-numpy package, nothing changes with regards to loading mmass.

Fingers crossed there are alternative options out there for me Thank you both for your suggestions so far.

All the best,
Farsight.

[tashirosgt]

Originally Posted by Farsight

I'm not really sure what would be a suitable application to use for testing. Any recommendations?

Try the Hello World program in python.
http://python.about.com/od/gettingst...oworld_all.htm

[marko]

Originally Posted by Farsight

Hi folks,

I've tried both options and had no success. In Ubuntu 12.04 and Fedora 16, the command echo $PYTHONPATH just returns a blank line. I've yet to try a simple python application - I'm not really sure what would be a suitable application to use for testing. Any recommendations?

Having installed the python3-numpy package, nothing changes with regards to loading mmass.

Fingers crossed there are alternative options out there for me Thank you both for your suggestions so far.

All the best,
Farsight.

Another thing to remember here, you're saying you've not tried a simple python application. The "yum" package installer tool is actually a very complex python application. If it works, you're very likely to have a good and working python installation. (that is, yum in normal usage exercises lots of python functionality so it's a good robustness test of your python). If yum works and mmass doesn't, the blame is more likely numpy, wxPython or any other imports that mmass uses that yum doesn't or mmass itself. Python itself has some debug flags you can set but like "-d" or "-W" but I suspect they'd just give you the same unhelpful warning it already shows.

[PabloTwo]

Not that I intend to utilize the mmass software, but to see if I could duplicate your problem, I downloaded the mmass repo file, cat'd it's contents and pasted the repo url into a new browser tab, then did a download of mmass-5.0.1-1.3.x86_64.rpm in the broswer. I installed it using yum, which brought in these dependencies:

Downloading Packages:
(1/8): numpy-1.6.1-2.fc16.x86_64.rpm
(2/8): python-nose-1.1.2-1.fc16.noarch.rpm
(3/8): python-setuptools-0.6.24-1.fc16.noarch.rpm
(4/8): wxBase-2.8.12-1.fc16.x86_64.rpm
(5/8): wxGTK-2.8.12-1.fc16.x86_64.rpm
(6/8): wxGTK-gl-2.8.12-1.fc16.x86_64.rpm
(7/8): wxGTK-media-2.8.12-1.fc16.x86_64.rpm
(8/8): wxPython-2.8.12.0-1.fc16.x86_64.rpm

I ran "mmass" from both the command line and from the menu. It loaded and ran without issue. If you launch mmass from the command line, does it give you any more verbose error message other than just "A problem in the python-2.7.3-1 package was detected"?, which isn't very informative.

As for reinstalling python...

yum reinstall python python-libs

[aleph]

Can't reproduce. Doubting whether this is related to the Python path configuration.

Since we're at it, the proper way to test the Python path at runtime is to inspect sys.path.
And this package seem to do a very unconventional install. It put its own library and executables under /usr/share which is a highly discouraged thing. Not that I'm saying this is the cause of the problem. Just FYI.

[tashirosgt]

Originally Posted by aleph

the proper way to test the Python path at runtime is to inspect sys.path.

Just to make sure we know how to do that, do we do it by starting the python interpeter with the command

python

and then use the commands (which I found on http://stackoverflow.com/questions/8...sys-path-value)

import sys
from pprint import pprint as p
p(sys.path)

?

And I gather that sys.path can be modified by Python application, so to do a valid test of mmass's sys.path, you'd have to run these commands (somehow) in the interpreter that is running mmass. Is that correct?

(I agrree that Farsight's problem doesn't seem to be with Python paths, but it is interesting to know how to check them.)

[marko]

What I found kind of odd is that I did a find of all the python code I could think of that the mmass could be using and then grepped it for the string "was detected" which was shown in the error message. I could find the error string nowhere in any *.py files in python, python-libs, wxPython, or mmass packages


Then I tried looking in the .so libraries of the same packages via the strings command:

strings /usr/bin/python2.7 | grep -i "detected"
strings /usr/share/mmass/mspy/calculations.so | grep "detected"

find /usr/lib64/python2.7/lib-dynload/ -type f -name '*.so" -exec grep -li "was detected" {} \; -print

then I used strings against the files reported by the find command above, still nothing matches the error message. So I'm not sure where it comes from.

[marko]

I downloaded the mmass rpm file and installed it just fine with:

yum install mmass-5.0.1-1.3.x86_64.rpm

and ran it:

mmass

mmass --> runs /usr/bin/mmass

which is a plain shell script that actually calls to "python /usr/share/mmass/mmass.py"

I ran it with the shell script and it worked ok.

I suspect you're just missing one of the dependencies that were listed in post 5. Note that the
mmass package has a doc directory that contains a pdf file /usr/share/doc/mmass-5.0.1/User Guide.pdf
you should look in it in sections 4.3 and 4.4, there's a C compile step but it seems all it does is make it
faster but there might be a hint in there.

[Farsight]

Ok folks, so I'm now home and able to have another go at working this problem out.

Firstly, thank you to Tashirosgt for the python application recommendation.

I've checked each and every one of the listed dependencies (I just did yum install 'dependency name'). All were installed. The difference in my system is that I am using the i386 system as opposed to the x64. Given that both Pablo and Marko have the x64 version of mmass working fine, maybe its something particular to i386 system environment?

Regarding the sys.path recommendation, I have to admit I am clueless about how I progress. My terminal knowledge is in its infancy. Perhaps someone could share the necessary commands I'll be needing? If what Tashirosgt has put is correct, my output is as follows:

>>> from pprint import pprint as p
>>> p(sys.path)
['',
'/usr/lib/python27.zip',
'/usr/lib/python2.7',
'/usr/lib/python2.7/plat-linux2',
'/usr/lib/python2.7/lib-tk',
'/usr/lib/python2.7/lib-old',
'/usr/lib/python2.7/lib-dynload',
'/usr/lib/python2.7/site-packages',
'/usr/lib/python2.7/site-packages/PIL',
'/usr/lib/python2.7/site-packages/gst-0.10',
'/usr/lib/python2.7/site-packages/gtk-2.0',
'/usr/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg-info',
'/usr/lib/python2.7/site-packages/wx-2.8-gtk2-unicode']

---------- Post added at 07:43 PM ---------- Previous post was at 07:15 PM ----------

Here is a link to the error message I receive:
[IMG=http://img444.imageshack.us/img444/9893/mmassandpythonerrorfedo.png][/IMG]

Uploaded with ImageShack.us

[tashirosgt]

I think the error message is from this software:https://fedoraproject.org/wiki/Features/CrashCatcher We'll have to think about how to use that fact.

[aleph]

It's quite amusing that the process got killed by SIGILL, illegal instruction. This could be a problem when the package compiled the binary dynamical shared object files.

[tashirosgt]

Simple things to try:

Note the time of day, recreate the error and then look in /var/log/messages and see if there is more information about it.

Try using some options on the the python command that may print out more info. Just from glancing at man python on my FC 12 machine, my guess is to run the program by

python -d -v /usr/share/mmass/mmass.py

Did you run "Hello World" yet?


I gather what's happening is that the python interprer attempts to do something that the kernel detects as improper, so the kernel sends the process a "signal" and kills it. If you can run "Hello World" and various other Python programs, it isn't the intepreter per se that is the problem.


In most computer languages, there are ways of writing relatively simple code to "handle signals". Such code can print out the a list of the the functions that were being used when the error occurred. If you're running the program from the command line, you would see such printout. Perhaps a Python programmer could put such code into mmass.py or perhaps if you contact the author of the program, he would do this. I speculate that it would be a useful feature, but I'm not sure of the technical details.

I'd think that the Python interpreter would have some capability to catch signals