[Bioperl-guts-l] [Bug 2184] segmentation error during BioPerl 1.5.2 installation

bugzilla-daemon at portal.open-bio.org bugzilla-daemon at portal.open-bio.org
Fri Jan 12 14:11:26 EST 2007


http://bugzilla.open-bio.org/show_bug.cgi?id=2184





------- Comment #9 from cjfields at uiuc.edu  2007-01-12 14:11 -------
As an added note (just to complicate the picture more), according to recent
posts in perl.dbi.dev there were some problems with recent version of
DBD::mysql causing seg faults which should be fixed in the latest CPAN version:

http://www.nntp.perl.org/group/perl.dbi.dev/4628

There are also some sporadic DBI seg fault issues reported; I am unsure if they
have been resolved in the last CPAN release (1.53):

http://www.nntp.perl.org/group/perl.dbi.dev/4710

(In reply to comment #8)
...
> Well yes, that is the whole purpose of these tests. First it checks to see if
> the modules load, and only if they load does it then check to see if the test
> database is connectable. We need some kind of connectivity test without any
> possibility of seg faulting. The question is, what test is suitable?

If the segfault is occurring at the point where the BioDBSeqFeature mysql/BDB
tests are checked, and since we're not sure what is causing the segfault (DBI,
DBD::mysql, or the local MySQL installation), then maybe the best short-term
solution would be to give the option of running BioDBSeqFeature MySQL/BDB tests
(similar to the optional BioDBGFF test), as opposed to the current behavior of
having them run automatically if MySQL/BDB is detected.  This would at least
work around potential seg faults.

The only ways I can think of to directly check MySQL connectivity which
probably wouldn't crash Build.PL would be (1) forking the MySQL check in
Build.PL to a separate process, then checking it's return status, or (2) or
check for MySQL connectivity using system() or backticks, then check for a
specific error or return status.  And I'm not sure whether either of those
would work, to tell the truth! 

Though it's not immediately relevant, there may be issues with any forked
processes on Windows since the fork() implementation is still experimental.

> > As a note, I'm not sure how Lincoln set up detecting the presence of MySQL but
> > it doesn't detect MySQL on Windows tests (it bypassed them).
> 
> This was quite deliberate but I suspect a hack around an unconfirmed and
> uninvestigated problem. If the test can and should pass under Windows, by all
> means the 'excludes_os      => ['mswin'],' line should be removed from Build.PL

I'll have to investigate whether it passes, but it should be filed as a bug if
it fails, unless it is explicitly stated somewhere that Windows/MySQL doesn't
work or isn't supported.

> > > In the mean time, to allow installation to proceed you'll have to hack 
> > 
> > You can always force install as well
> 
> force install only works when tests are failing. In this case, Build.PL is seg
> faulting; only Build.PL knows what to install and how, so there is nothing to
> 'force'.

Yep, you're right.  Really no way around it.


-- 
Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


More information about the Bioperl-guts-l mailing list