Bug#905206: Seems to crash in fortran lib

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#905206: Seems to crash in fortran lib

Olivier Sallou-3


Le jeu. 3 oct. 2019 à 12:08, Michael Crusoe <[hidden email]> a écrit :
On Sat, 9 Mar 2019 17:44:02 +0100 olivier sallou <[hidden email]> wrote:
> Looking at core generated file and using gdb we see that it fails in
> fortran lib.
>
> Either program tries something wrong in a fortran updated lib version,
> either the fortran lib is itself buggy.
>
> I have no fortran knowledge to debug this however. And it lacks debug info
> to find calling line in profnet.

The debug symbols exists for non-amd64 archs: https://packages.debian.org/sid/profnet-snapfun-dbgsym

Fun to see it in different arch but not amd64... Will give a try when possible.


So you can make your own debug symbols locally by rebuilding the package, or someone could upload a new source package as it has been almost a year. I made some cosmetic cleanups to the Debian packaging if that is a good enough excuse (though snapfun still segfaults for me)

>
> Test: rofnet_snapfun switch 385 55 10 46 100 PROFin.dat PROFacc_tst.jct
> none dbg
>
> Gdb result:
>
> Core was generated by `profnet_snapfun switch 385 55 10 46 100 PROFin.dat
> PROFacc_tst.jct none dbg'.

--
Michael
Reply | Threaded
Open this post in threaded view
|

Bug#905206: Seems to crash in fortran lib

Michael Crusoe
Here is the crash with debug symbols (courtesy libc6-dbg libgfortran5-dbg and a locally created profnet-snapfun-dbgym)

root@mrc-tux:/tmp# profnet_snapfun switch 385 55 10 46 100 PROFin.dat PROFacc_tst.jct none

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7faaf117e0ff in ???
at /build/glibc-sPWrSm/glibc-2.29/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
#1  0x7faaf1680018 in formatted_transfer_scalar_read
at ../../../src/libgfortran/io/transfer.c:1649
#2  0x7faaf1681803 in formatted_transfer
at ../../../src/libgfortran/io/transfer.c:2326
#3  0x55a7ca3a63c6 in rdjct_jct2_
at ./snapfun_dir/prof.f:1042
#4  0x55a7ca3a7c64 in rdjct_
at ./snapfun_dir/prof.f:876
#5  0x55a7ca3b0967 in prof
at ./snapfun_dir/prof.f:108
#6  0x55a7ca39f25e in main
at ./snapfun_dir/prof.f:179
Segmentation fault (core dumped)

On Thu, Oct 3, 2019 at 12:35 PM olivier sallou <[hidden email]> wrote:


Le jeu. 3 oct. 2019 à 12:08, Michael Crusoe <[hidden email]> a écrit :
On Sat, 9 Mar 2019 17:44:02 +0100 olivier sallou <[hidden email]> wrote:
> Looking at core generated file and using gdb we see that it fails in
> fortran lib.
>
> Either program tries something wrong in a fortran updated lib version,
> either the fortran lib is itself buggy.
>
> I have no fortran knowledge to debug this however. And it lacks debug info
> to find calling line in profnet.

The debug symbols exists for non-amd64 archs: https://packages.debian.org/sid/profnet-snapfun-dbgsym

Fun to see it in different arch but not amd64... Will give a try when possible.


So you can make your own debug symbols locally by rebuilding the package, or someone could upload a new source package as it has been almost a year. I made some cosmetic cleanups to the Debian packaging if that is a good enough excuse (though snapfun still segfaults for me)

>
> Test: rofnet_snapfun switch 385 55 10 46 100 PROFin.dat PROFacc_tst.jct
> none dbg
>
> Gdb result:
>
> Core was generated by `profnet_snapfun switch 385 55 10 46 100 PROFin.dat
> PROFacc_tst.jct none dbg'.

--
Michael


--
Reply | Threaded
Open this post in threaded view
|

Bug#905206: Seems to crash in fortran lib

Olivier Sallou-3


Le jeu. 3 oct. 2019 à 12:58, Michael Crusoe <[hidden email]> a écrit :
Here is the crash with debug symbols (courtesy libc6-dbg libgfortran5-dbg and a locally created profnet-snapfun-dbgym)

root@mrc-tux:/tmp# profnet_snapfun switch 385 55 10 46 100 PROFin.dat PROFacc_tst.jct none

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

I really do not see what error could be. Maybe a fortran issue after an upgrade (something that was working but not done the same way now....)
Sorry, I have no skill to fix this kind of issue. Should be reported upstream

I see on their web site that it was superseeded by snap2 in 2015. So maybe time to let it go....
 

Backtrace for this error:
#0  0x7faaf117e0ff in ???
at /build/glibc-sPWrSm/glibc-2.29/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
#1  0x7faaf1680018 in formatted_transfer_scalar_read
at ../../../src/libgfortran/io/transfer.c:1649
#2  0x7faaf1681803 in formatted_transfer
at ../../../src/libgfortran/io/transfer.c:2326
#3  0x55a7ca3a63c6 in rdjct_jct2_
at ./snapfun_dir/prof.f:1042
#4  0x55a7ca3a7c64 in rdjct_
at ./snapfun_dir/prof.f:876
#5  0x55a7ca3b0967 in prof
at ./snapfun_dir/prof.f:108
#6  0x55a7ca39f25e in main
at ./snapfun_dir/prof.f:179
Segmentation fault (core dumped)

On Thu, Oct 3, 2019 at 12:35 PM olivier sallou <[hidden email]> wrote:


Le jeu. 3 oct. 2019 à 12:08, Michael Crusoe <[hidden email]> a écrit :
On Sat, 9 Mar 2019 17:44:02 +0100 olivier sallou <[hidden email]> wrote:
> Looking at core generated file and using gdb we see that it fails in
> fortran lib.
>
> Either program tries something wrong in a fortran updated lib version,
> either the fortran lib is itself buggy.
>
> I have no fortran knowledge to debug this however. And it lacks debug info
> to find calling line in profnet.

The debug symbols exists for non-amd64 archs: https://packages.debian.org/sid/profnet-snapfun-dbgsym

Fun to see it in different arch but not amd64... Will give a try when possible.


So you can make your own debug symbols locally by rebuilding the package, or someone could upload a new source package as it has been almost a year. I made some cosmetic cleanups to the Debian packaging if that is a good enough excuse (though snapfun still segfaults for me)

>
> Test: rofnet_snapfun switch 385 55 10 46 100 PROFin.dat PROFacc_tst.jct
> none dbg
>
> Gdb result:
>
> Core was generated by `profnet_snapfun switch 385 55 10 46 100 PROFin.dat
> PROFacc_tst.jct none dbg'.

--
Michael


--
Reply | Threaded
Open this post in threaded view
|

Bug#905206: Seems to crash in fortran lib

Andreas Tille-2
Hi Olivier,

On Fri, Oct 04, 2019 at 02:14:02PM +0200, olivier sallou wrote:
> > Program received signal SIGSEGV: Segmentation fault - invalid memory
> > reference.
>
> I really do not see what error could be. Maybe a fortran issue after an
> upgrade (something that was working but not done the same way now....)
> Sorry, I have no skill to fix this kind of issue. Should be reported
> upstream

Since Laszlo changed his job we do not have real upstream contact.
 
> I see on their web site that it was superseeded by snap2 in 2015. So maybe
> time to let it go....

Fine for me.  Where exactly did you found this?  I only found a snap^2
web interface.  What about the reverse depends of profnet?

Kind regards

      Andreas.

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Bug#905206: Additional remark to: Status of rostlab software in Debian (Was: Bug#905206: Seems to crash in fortran lib)

Andreas Tille-5
Hello again,

another package originated at RostLab is currently creating issues
as it is reported against the package profphd
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942064#17).
The bug report quotes the following hint:

    Make prof work with Debian Jessie by requiring perlbrew package
    and have it install independent perl v5.10 instance. $[ has been
    moved from perl core >=5.16.0 into arybase, and does not produce
    the same side effects as in previous perl versions, therefore
    breaking prof when run using perl v5.20 in Jessie.

Currently Debian is moving to Perl v5.30 and we have no power to port
all code that is even orphaned by its original authors.  But before we
give up we want to make really sure what you think about it.  I wonder
whether some member of your group might find some time to clarify the
need to keep this software or what the more up to date replacements
might be.  We'd happily support you in packaging the latest and greatest
code from your lab.

Kind regards and thanks a lot for your cooperation

     Andreas.


On Tue, Oct 08, 2019 at 04:47:12PM +0200, Andreas Tille wrote:

> Hello,
>
> back in 2009 Laszlo Kajan did quite some effort to package several
> projects from rostlab.org for official Debian.  There was a very good
> cooperation between RostLab and Debian - mediated by Laszlo who was
> introducing other members (who probably left Rostlab meanwhile to find
> other jobs).
>
> Since Laszlo moved away from Munich he lost contact to Rostlab and had
> also no time to keep on maintaining the existing Software inside Debian.
> So the Debian Med team took over the maintenance.  The packages were
> regularly updated to latest versions released by Rostlab as well as to
> the latest packaging standards in Debian.  This also included continuous
> integration tests to verify the functionality of the programs.
>
> It now turned out that one of the tests for profnet failed (you might
> like to read the full story and the effort we did to track the issue
> down in the according bug report https://bugs.debian.org/905206 ).
> The reason seems to be inside a FORTRAN module
> (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905206#69 ).
> Unfortunately there is nobody in the team who can even decide whether
> this might be caused by a broken gfortran compiler or whether the code
> is broken.  Thus we can not guarantee the proper functionality of the
> code for our users without help.
>
> As you can read below Olivier Sallou from Debian Med team found reasons
> to assume that the software stack based on profnet is superseeded
> anyway.  It would be nice if you could confirm this.  In this case we
> could stop our desperate efforts to get profnet fully functional again.
>
> If you consider that packaging SNAP2 is more fruitful - may be other
> software you would like to see inside Debian - we would rather
> concentrate on this and would be happy to package your latest and
> greatest code.
>
> In general we would love to refresh the closer relation between RostLab
> and Debian since Laszlo made us believe this would be quite fruitfully.
> May be you would like to send a member of your lab to our next Sprint
> which will happen somewhen in the beginning of next year in Berlin (to
> be announced).  Such kind of sprint once was the entry point for Laszlo
> into Debian.  Inside the Debian Med team we have quite a record for
> teaching about Debian packaging which could be quite interesting for
> you.
>
> I'd be really happy to revive the connection again.
>
> Kind regards
>
>        Andreas.
>
> On Tue, Oct 08, 2019 at 09:26:13AM +0200, Olivier Sallou wrote:
> >
> > On 10/4/19 3:07 PM, Andreas Tille wrote:
> > > Hi Olivier,
> > >
> > > On Fri, Oct 04, 2019 at 02:14:02PM +0200, olivier sallou wrote:
> > >>> Program received signal SIGSEGV: Segmentation fault - invalid memory
> > >>> reference.
> > >> I really do not see what error could be. Maybe a fortran issue after an
> > >> upgrade (something that was working but not done the same way now....)
> > >> Sorry, I have no skill to fix this kind of issue. Should be reported
> > >> upstream
> > > Since Laszlo changed his job we do not have real upstream contact.
> > >  
> > >> I see on their web site that it was superseeded by snap2 in 2015. So maybe
> > >> time to let it go....
> > > Fine for me.  Where exactly did you found this?
> >
> > On https://rostlab.org/owiki/index.php/Snapfun:
> >
> > """
> >
> > 2015-07-23 : The Snapfun (SNAPweb service) has been superseded by an
> > improved version of SNAP, named SNAP2. Requests for the SNAPweb service
> > now point to SNAP2. If for some reason, you require the original SNAPweb
> > service, please contact [hidden email]. More information about SNAP2
> > is available here.
> >
> > """
> >
> >
> > Snap2 links:
> >
> > https://rostlab.org/owiki/index.php/Snap2
> >
> > https://github.com/Rostlab/SNAP2
> >
> >
> > >  I only found a snap^2
> > > web interface.  What about the reverse depends of profnet?
> >
> > this is indeed an issue, but if "old" release is not maintained anymore
> > and if we don't have local skills on this....
> >
> > This kind of issue goes beyond "maintainer" packaging, need skills in
> > language and software itself.
> >
> > >
> > > Kind regards
> > >
> > >       Andreas.
> > >
> > --
> > Olivier Sallou
> > Univ Rennes, Inria, CNRS, IRISA
> > Irisa, Campus de Beaulieu
> > F-35042 RENNES - FRANCE
> > Tel: 02.99.84.71.95
> >
> > gpg key id: 4096R/326D8438  (keyring.debian.org)
> > Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438
> >
> >
>
> --
> http://fam-tille.de
>
>

--
http://fam-tille.de