Bug#906980: kmer: autopkgtest fails with segfault in testing/unstable while it passes in stable
Hi Andreas, On Mon, 27 Aug 2018 at 17:02 Andreas Tille wrote: > > Ah, finally a pretty simple solution for a quite hidden problem. > I admit I have expected something more serious :-) > BTW, I wonder whether there are tools that would warn about issues > described in[1] - I think there are good means to detect this > automatically. > I checked clang-tidy and it can warn about such issues. One more tool I would like to know now together with continuing of learning C. > Would you please forward this solution to upstream? May be once you > contact upstream asking for a versioned release for download would be a > good idea. > I wrote to upstream about the bug. Hope, they are interested in providing new releases. > Please note that I moved the data file into a separate package > kmer-examples to avoid duplication of the data files and enable users > installing the code without the data. Thus the package needs to pass > the new queue (hope this will happen soon). > Yes, thank you for this! I was not sure about putting data in a separate package as the data were small and there were no lintian warnings about this. Thanks a lot for you fine work. I think this issue is something you > can be really proud about since your work uncovered an issue and you > finally was able to fix it. I was happy to finally delete kmer from my list as it was hanging for so long :-P > I really hope you will be able to > continue this work even if GSoC is close to finished. May be, if you > have time you could continue a bit. I'd be very happy about this. > Many, many thanks to you for mentoring me! I definitely have time till September 10 before my master program starts. I would like to look into unicycler and maybe something else. With regards, Liubov
Bug#906980: kmer: autopkgtest fails with segfault in testing/unstable while it passes in stable
Control: tags -1 pending Hi Liubov, On Mon, Aug 27, 2018 at 12:36:22PM +0200, Liubov Chuprikova wrote: > > > it in clean chroot). JFI, I tried installing an older version of gcc on > > > testing, the one that is used in stable (4:6.3.0-4), and this eliminated > > > the segfault. > > > > Thanks for this good catch which proves how important your Outreachy > > project is for providing stable and working packages in Debian Med. > > Now I see! :-) > Thanks a lot for your advise! I tried debugging with grep when I had just > caught the error for the first time, but it was without result at that > moment. Turning off optimization flags, as you recommended, also did not > help. After that I made one more attemp to debug with grep and printing > some statements and finally found what it is called classical non-bug in > gcc [1]. Ah, finally a pretty simple solution for a quite hidden problem. BTW, I wonder whether there are tools that would warn about issues described in[1] - I think there are good means to detect this automatically. Would you please forward this solution to upstream? May be once you contact upstream asking for a versioned release for download would be a good idea. > I have just uploaded a patch. Could you please sponsor an upload? I did. Unfortunately I created quite some mess in the Git repository. I was traveling yesterday, found a patch for bug #907007 and uploaded without further checking. To make things worse I forgot to push my changes due to bad bandwidth. I tried hard to get your commits right again to keep some sensible history. I hope its not so confusing - at least the resulting code in debian/ dir is correct ... Please note that I moved the data file into a separate package kmer-examples to avoid duplication of the data files and enable users installing the code without the data. Thus the package needs to pass the new queue (hope this will happen soon). Thanks a lot for you fine work. I think this issue is something you can be really proud about since your work uncovered an issue and you finally was able to fix it. I really hope you will be able to continue this work even if GSoC is close to finished. May be, if you have time you could continue a bit. I'd be very happy about this. Kind regards and thanks again Andreas. > [1] https://gcc.gnu.org/bugs/#nonbugs_c -- http://fam-tille.de
Bug#906980: kmer: autopkgtest fails with segfault in testing/unstable while it passes in stable
Hi Andreas,
On Thu, 23 Aug 2018 at 08:58 Andreas Tille wrote:
>
> On Wed, Aug 22, 2018 at 09:42:13PM +0200, Liubov Chuprikova wrote:
> > An autopkgtest fails with segfault in testing and unstable [1].
> >
> > ```
> > /usr/bin/../lib/atac/bin/statsGenerator -a
> /tmp/autopkgtest-lxc.epng5fx9/downtmp/autopkgtest_tmp/results/EcolivsSent.atac
> > -p
> /tmp/autopkgtest-lxc.epng5fx9/downtmp/autopkgtest_tmp/results/stats/EcolivsSent
> > -g A >
> /tmp/autopkgtest-lxc.epng5fx9/downtmp/autopkgtest_tmp/results/stats/EcolivsSent.stats
> >
> > Segmentation fault
> > Failed to ganerate statistics.
> > ```
> >
> > Notably, that building and testing in stable were successful (I tested
> > it in clean chroot). JFI, I tried installing an older version of gcc on
> > testing, the one that is used in stable (4:6.3.0-4), and this eliminated
> > the segfault.
>
> Thanks for this good catch which proves how important your Outreachy
> project is for providing stable and working packages in Debian Med.
>
Now I see!
> Thanks also for verifying that older compilers seem to produce working
> code while newer don't.
>
This seemed just something to go on.
I wonder whether you feel able to do some debugging what position of
> code causes the issue.
My first shout would be to grep for
>"Failed to ganerate statistics"
> which is probably in a wrapper around some code and than use some
> debugging techniques (either you are comfortable with gdb / want to
> become comfortable with gdb or simply use some
> printf("DEBUG %s(%i): ...", __FILE__, __LINE__, ...);
> statements in the code to watch what's happening.
> It might be helpful to lower / switch off optimisation options to see
> whether some optimisation feature of some later gcc will deal
> differently with some not properly specified code part.
>
Thanks a lot for your advise! I tried debugging with grep when I had just
caught the error for the first time, but it was without result at that
moment. Turning off optimization flags, as you recommended, also did not
help. After that I made one more attemp to debug with grep and printing
some statements and finally found what it is called classical non-bug in
gcc [1].
I have just uploaded a patch. Could you please sponsor an upload?
With regards,
Liubov
[1] https://gcc.gnu.org/bugs/#nonbugs_c
Bug#906980: kmer: autopkgtest fails with segfault in testing/unstable while it passes in stable
Hi Liubov,
On Wed, Aug 22, 2018 at 09:42:13PM +0200, Liubov Chuprikova wrote:
> An autopkgtest fails with segfault in testing and unstable [1].
>
> ```
> /usr/bin/../lib/atac/bin/statsGenerator -a
> /tmp/autopkgtest-lxc.epng5fx9/downtmp/autopkgtest_tmp/results/EcolivsSent.atac
> -p
> /tmp/autopkgtest-lxc.epng5fx9/downtmp/autopkgtest_tmp/results/stats/EcolivsSent
> -g A >
> /tmp/autopkgtest-lxc.epng5fx9/downtmp/autopkgtest_tmp/results/stats/EcolivsSent.stats
>
> Segmentation fault
> Failed to ganerate statistics.
> ```
>
> Notably, that building and testing in stable were successful (I tested
> it in clean chroot). JFI, I tried installing an older version of gcc on
> testing, the one that is used in stable (4:6.3.0-4), and this eliminated
> the segfault.
Thanks for this good catch which proves how important your Outreachy
project is for providing stable and working packages in Debian Med.
Thanks also for verifying that older compilers seem to produce working
code while newer don't.
I wonder whether you feel able to do some debugging what position of
code causes the issue. My first shout would be to grep for
"Failed to ganerate statistics"
which is probably in a wrapper around some code and than use some
debugging techniques (either you are comfortable with gdb / want to
become comfortable with gdb or simply use some
printf("DEBUG %s(%i): ...", __FILE__, __LINE__, ...);
statements in the code to watch what's happening.
It might be helpful to lower / switch off optimisation options to see
whether some optimisation feature of some later gcc will deal
differently with some not properly specified code part.
Please let me know if you need further advise.
Kind regards
Andreas.
--
http://fam-tille.de
Bug#906980: kmer: autopkgtest fails with segfault in testing/unstable while it passes in stable
Package: kmer Version: 0~20150903+r2013-4 Severity: serious Justification: reproducibility An autopkgtest fails with segfault in testing and unstable [1]. ``` /usr/bin/../lib/atac/bin/statsGenerator -a /tmp/autopkgtest-lxc.epng5fx9/downtmp/autopkgtest_tmp/results/EcolivsSent.atac -p /tmp/autopkgtest-lxc.epng5fx9/downtmp/autopkgtest_tmp/results/stats/EcolivsSent -g A > /tmp/autopkgtest-lxc.epng5fx9/downtmp/autopkgtest_tmp/results/stats/EcolivsSent.stats Segmentation fault Failed to ganerate statistics. ``` Notably, that building and testing in stable were successful (I tested it in clean chroot). JFI, I tried installing an older version of gcc on testing, the one that is used in stable (4:6.3.0-4), and this eliminated the segfault. [1] https://ci.debian.net/packages/k/kmer/ -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
