Bug#905206: profnet: autopkgtest regression

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

Bug#905206: profnet: autopkgtest regression

Graham Inggs-3
Source: profnet
Version: 1.0.22-5
X-Debbugs-CC: [hidden email]
User: [hidden email]
Usertags: regression

Hi Maintainer

Since the upload of 1.0.22-5, profnet fails its autopkgtests [1] with
the following error:

autopkgtest [02:16:50]: @@@@@@@@@@@@@@@@@@@@ summary
command1             PASS
command2             PASS
command3             PASS
command4             PASS
command5             FAIL non-zero exit status 139

autopkgtest [02:16:49]: test command5: [-----------------------

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

Backtrace for this error:
#0  0x7efe4bafe0ba
#1  0x7efe4bafd2d3
#2  0x7efe4afc071f
#3  0x7efe4bc699cb
#4  0x7efe4bc6aa8b
#5  0x7efe4bc6dc20
#6  0x7efe4bc6f1fc
#7  0x5612e8fd4f84
#8  0x5612e8fd674c
#9  0x5612e8fdf1fd
#10  0x5612e8fcdfde
#11  0x7efe4afacf29
#12  0x5612e8fce019
#13  0xffffffffffffffff
Segmentation fault

Regards
Graham


[1] https://ci.debian.net/packages/p/profnet/unstable/amd64/

Reply | Threaded
Open this post in threaded view
|

Bug#905206: Seems to crash in fortran lib

Olivier Sallou-3
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.

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'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fcc9b08e2fa in ?? () from /lib/x86_64-linux-gnu/libgfortran.so.5
(gdb) where
#0  0x00007fcc9b08e2fa in ?? () from /lib/x86_64-linux-gnu/libgfortran.so.5
#1  0x00007fcc9b08f49d in ?? () from /lib/x86_64-linux-gnu/libgfortran.so.5
#2  0x00007fcc9b092611 in ?? () from /lib/x86_64-linux-gnu/libgfortran.so.5
#3  0x00007fcc9b093bad in ?? () from /lib/x86_64-linux-gnu/libgfortran.so.5
#4  0x00007fcc9b090d49 in _gfortran_transfer_array () from /lib/x86_64-linux-gnu/libgfortran.so.5
#5  0x000055ccaf6513fe in ?? ()
#6  0x000055ccaf652c65 in ?? ()
#7  0x000055ccaf65ba8e in ?? ()
#8  0x000055ccaf64a25f in ?? ()
--Type <RET> for more, q to quit, c to continue without paging--
#9  0x00007fcc9ab0009b in __libc_start_main (main=0x55ccaf64a240, argc=11, argv=0x7fff2520e418, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7fff2520e408) at ../csu/libc-start.c:308
#10 0x000055ccaf64a29a in ?? ()
Reply | Threaded
Open this post in threaded view
|

Bug#905206: Do you have some spare cycles to have a look at this (Was: profnet is marked for autoremoval from testing)

Andreas Tille-5
In reply to this post by Graham Inggs-3
Hi Shayan,

On Mon, Sep 16, 2019 at 04:39:03AM +0000, Debian testing autoremoval watch wrote:
> profnet 1.0.22-6 is marked for autoremoval from testing on 2019-09-26
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

This bug is quite some nuisance since several packages depend from profnet
and it seems nobody has an idea how to fix it.  Would you be able to have
a look?

Kind regards

     Andreas.

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Bug#905206: Do you have some spare cycles to have a look at this (Was: profnet is marked for autoremoval from testing)

Andreas Tille-2
In reply to this post by Graham Inggs-3
Hi Shayan,

On Sat, Sep 21, 2019 at 05:23:49PM +0100, Shayan Doust wrote:
> This is new territory - I have spent some time looking at this and so far I
> could only reproduce all of what was already mentioned above.

It might become time consuming.
 
> I will later go more in-depth and try using mem profiling / debugging and
> some trial and error to try figure out why this gets a segmentation fault
> because this issue is really annoying and needs rectifying.

In any case yes. While I guess the program is not used in really security
relevant context you can never know and this kind of crash is a security
issue (besides the fact that it just does not the job its supposed to do).

Thanks for working at this

      Andreas.

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Bug#905206: Do you have some spare cycles to have a look at this (Was: profnet is marked for autoremoval from testing)

Andreas Tille-2
Hi Shayan,

more pinging the bug to extend the period the package stays in testing but
in case you might have any temporary results for this issue feel free to
post these here.

Kind regards, Andreas.

On Sat, Sep 21, 2019 at 07:05:27PM +0200, Andreas Tille wrote:

> Hi Shayan,
>
> On Sat, Sep 21, 2019 at 05:23:49PM +0100, Shayan Doust wrote:
> > This is new territory - I have spent some time looking at this and so far I
> > could only reproduce all of what was already mentioned above.
>
> It might become time consuming.
>  
> > I will later go more in-depth and try using mem profiling / debugging and
> > some trial and error to try figure out why this gets a segmentation fault
> > because this issue is really annoying and needs rectifying.
>
> In any case yes. While I guess the program is not used in really security
> relevant context you can never know and this kind of crash is a security
> issue (besides the fact that it just does not the job its supposed to do).
>
> Thanks for working at this
>
>       Andreas.
>
> --
> http://fam-tille.de
>

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Bug#905206: Seems to crash in fortran lib

Michael Crusoe
In reply to this post by Graham Inggs-3
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

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: [Debian-med-packaging] Bug#905206: Seems to crash in fortran lib

Olivier Sallou
In reply to this post by Graham Inggs-3

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

Reply | Threaded
Open this post in threaded view
|

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

Andreas Tille-5
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