search

rdmenezes / orthagogue

Automatically exported from code.google.com/p/orthagogue
Other
0 stars 0 forks source link

segmentation fault #5

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Hi, I installed orthAgogue, then built a toy input file (see attached file).
When I launch orthAgogue with the following line:

orthAgogue -i esempio_toy

I got a Segmentation fault error.
Looking for some insights, I used gdb to launch orthAgogue, and got this:

Starting program: orthAgogue -i esempio_toy
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff634e700 (LWP 52036)]

Program received signal SIGSEGV, Segmentation fault.
__strchr_sse2 () at ../sysdeps/x86_64/multiarch/../strchr.S:32
32  ../sysdeps/x86_64/multiarch/../strchr.S: No such file or directory.

Do you have any clue about this?
Best,
Emanuele

Original issue reported on code.google.com by bosieman...@gmail.com on 5 Jun 2014 at 2:57

Attachments:

GoogleCodeExporter commented 9 years ago 
Hi,

Thanks for your query! ;)

> warning: Could not load shared library symbols for linux-vdso.so.1.

The extract (from your error-message) indicates problems with a linked library:
-- as "strchr" is part of the "libc.so" library (ie, a shared library), a 
reasonable guess is to assume that "libc" is not properly linked to orthAgogue.

In order to solve this issue (given above observation), I'd be thankful if you 
could have a look upon my below questions:
(1) how did you install the software (ie by using the debian/rpm packages, or 
from the repository)?
(2) what are the dependencies of your "orthAgogue" program (which are found 
"ldd orthAgogue" command from your terminal)?

Looking forward for your reply! ;)

Ole Kristian Ekseth

Original comment by oeks...@gmail.com on 5 Jun 2014 at 5:17

GoogleCodeExporter commented 9 years ago 
Hi,
I installed using the debian package (dpkg -i DEBFILE), after this issue I 
tried also installing from source (./install_bash), but I was unable to solve 
it.
This is the output of ldd orthAgogue:

    linux-vdso.so.1 (0x00007fff2b600000)
    libcmph.so.0 => /usr/lib/x86_64-linux-gnu/libcmph.so.0 (0x00007f8810b90000)
    libtbb.so.2 => /usr/lib/libtbb.so.2 (0x00007f8810958000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8810648000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8810340000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8810128000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f880fd78000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f880fb70000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f880f950000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f880f748000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f8810dd8000)

Thanks for your reply,
Emanuele

Original comment by bosieman...@gmail.com on 6 Jun 2014 at 8:44

GoogleCodeExporter commented 9 years ago 
Hi,

Thanks for your help! ;)
-- Have skimmed some forums (on the web) to understand the issue;
-- the observed symptoms (as stated in your posts) comes from GDB (and not from 
linking of "libc", as first thought).

From a dive into the code (using "valgrind", which I prefer), I realized the 
problem was due to your sample-file not following the BlastP-spec:
(1) columns are (in blastP files) seperated by tabs ('\t') and not spaces 
(which was used in your file);
(2) a blastp-comparsison always includes a self-comparison (which was omitted 
in your sample-file);

From the above list, the following fixes are made:
-- In order to simplify construction of sample-blastp-files, I've now included 
support for multiple spaces (as column separator).
-- For your sample-protein-pairs, I've made a modified version: 
https://orthagogue.googlecode.com/hg-history/d9738007aebff161062419b2934325ffb0b
6ef4a/blastp_files/esempio_toy_modified.blast 

If you would have a a look upon the changes (by making a new clone/download 
from the repository), then I'd be thankful1 ;)
-- For details of the changes, see 
https://code.google.com/p/orthagogue/source/detail?r=d9738007aebff161062419b2934
325ffb0b6ef4a
-- if the changes solves your issue, then I'll (after your feedback) build new 
dbeian/rpm binary packages.
-- for small sample files (to play with), see the "blastp_files/" directory (in 
the source tree).

Hope this solved the issue, ie, I'm looking foward hearing from you:
-- if there are other issues, then I'd do my uthomst helping you! ;)

Ole Kristian

Original comment by oeks...@gmail.com on 6 Jun 2014 at 11:07

GoogleCodeExporter commented 9 years ago 
Thanks for your help Ole, very appreciated!
Yes, the blast TAB output has not spaces (\s), nevertheless I think that a
not-so-strict parser is preferable just in case some users are processing
the blast output (in my case I used awk to rename the protein names right
after the blast, resulting in a file with spaces instead of tabs).
I will try the modified version and will tell you more, unfortunately I
cannot look over the code (I don't use C :( anyway I trust you).
A little curiosity: Is orthagogue able to accept InParanoid tables as
output? In my specific case, I had performed InParanoid for ~ 70 genomes,
but multiparanoid crashes. Can I feed the inparanoid output to orthAgogue,
to avoid redoing the blast phase?
Thank you very much,
Emanuele

Original comment by bosieman...@gmail.com on 6 Jun 2014 at 12:40

GoogleCodeExporter commented 9 years ago 
Hi,

> Yes, the blast TAB output has not spaces (\s), nevertheless I think that a
> not-so-strict parser is preferable just in case some users are processing
> the blast output (in my case I used awk to rename the protein names right
> after the blast, resulting in a file with spaces instead of tabs).

-- Interesting; I fully agree with you, ie, thanks for making me aware of (such 
a) use case! ;)

> A little curiosity: Is orthagogue able to accept InParanoid tables as
> output? In my specific case, I had performed InParanoid for ~ 70 genomes,
> but multiparanoid crashes.

-- Should be possible to add such a feature. My first though is to write a 
Perl-script converting the inparanoid-table into blastP format (using 'dummy' 
content on non-defined columns/-attributes):
-- If you would send me a sample-file (illustrating/describing the format of 
Inparanoid tables), then I'll (hopefully) write a parser in one of the next 
days.

Ole Kristian

Original comment by oeks...@gmail.com on 6 Jun 2014 at 12:59