Bug#918856: RFS: rmlint/2.8.0-2

[Carlos Maddela]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "rmlint"

 * Package name: rmlint
   Version : 2.8.0-2
   Upstream Author : Christopher Pahl 
 * URL : https://rmlint.readthedocs.io/
 * License : GPL-3+
   Section : utils

  It builds these binary packages:

rmlint - Extremely fast tool to remove filesystem lint
 rmlint-doc - HTML documentation for rmlint
 rmlint-gui - GTK+ frontend to rmlint

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/rmlint


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/r/rmlint/rmlint_2.8.0-2.dsc

  Changes since the last upload:

  * Fix debian/tests/privacy-breach test to account for change
in document location.
  * Allow debhelper to handle stripping of binaries.
  * Build with Debhelper compat level 12.
  * Remove unnecessary build dependencies for nocheck build profile.
  * Fix builds for hurd, kfreebsd and sparc64 by relaxing build dependency
on python3-psutil for those architectures. It currently doesn't support
those architectures and is only required for running tests anyway.
  * Fix nosetests search.
  * Fix program termination by SIGILL signal, by removing sse4 instructions.
  * Update debian/clean list.


  Regards,
   Carlos Maddela

Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Andrey Rahmatullin]

On Wed, Jan 09, 2019 at 10:49:48PM +0100, Andreas Tille wrote:
> > > to find the exact code line[2] where the SIGSEGV is thrown.  It turns out
> > > that the elements of a structure are not accessible:
> > > 
> > >(gdb) print entry->offset
> > >Cannot access memory at address 0x7
> > It's because entry is 0x7.
> 
> When I was running the code with some more debugging info activated[1]
> I had pretty valid looking adresses 0x555666 
And still SEGV?

> > > The values of the structure are set in line 350[3] and are OK there.
> > The problem is not about the structure fields but about the structure
> > pointer itself though.
> > ...
> > You need to find out why one of the tree nodes has an invalid address.
> 
> Can you propose any means to find this out?
As usual: reading the code, debugging, printfs. Address sanitizer and/or
valgrind may or may not help too.

> I have no idea about specific compiler differences.
I don't think pondering compiler differences can be helpful here, it's
most likely bad code that is working file with some compilers but is still
bad code.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Andreas Tille]

Hi,

On Thu, Jan 10, 2019 at 02:14:14AM +0500, Andrey Rahmatullin wrote:
> On Wed, Jan 09, 2019 at 09:42:43PM +0100, Andreas Tille wrote:
> > to find the exact code line[2] where the SIGSEGV is thrown.  It turns out
> > that the elements of a structure are not accessible:
> > 
> >(gdb) print entry->offset
> >Cannot access memory at address 0x7
> It's because entry is 0x7.

When I was running the code with some more debugging info activated[1]
I had pretty valid looking adresses 0x555666 (or something in that line
just remembering by heart - can activate the patch if needed).  I have
no idea why the address is this without that extra debug code.
 
> > The values of the structure are set in line 350[3] and are OK there.
> The problem is not about the structure fields but about the structure
> pointer itself though.
> ...
> You need to find out why one of the tree nodes has an invalid address.

Can you propose any means to find this out?  I have no idea about
specific compiler differences.  BTW, I also tried to set -O0 but this
did not avoided the SIGSEGV.

Thanks for your hint anyway

  Andreas.

[1] 
https://salsa.debian.org/med-team/ffindex/blob/master/debian/patches/debug_segfault

-- 
http://fam-tille.de

Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Ole Streicher]

Hi Andreas,

one thing I usually do in such cases is to rebuild the package adding
"-fsanitize=address -O0" flags (optimization just to understand better
what happens in the source). This switches the address sanitizer on
. This can
test if a local variable is accidently overwritten (by an off-by-one
error or similar). Often it finds many more bugs which one can turn
upstream into bonus points...

Otherwise I see no other chance than to go through the debugger and see
where the strange address was set. 0x7 however sounds that somewhere a
small integer was assigned to the pointer, so I would try the sanitizing
stuff first.

Cheers

Ole

Andreas Tille  writes:
> Hi,
>
> as reported in bug #907624 ffindex autopkgtest fails with SIGSEGV in sid
> and buster.  I've tested in stretch (gcc 6.3) and the code works fine.
> I've reported upstream[1] the results of my gdb session where I was able
> to find the exact code line[2] where the SIGSEGV is thrown.  It turns out
> that the elements of a structure are not accessible:
>
>(gdb) print entry->offset
>Cannot access memory at address 0x7
>
> (full gdb log under [1] or in the bug log).
>
> In fact I tried in some more detailed debugging that any attempt to
> access one of the structure elements even for instance only injecting
> something like 
>
>if ( !entry->offset ) {
>
> in line 554 will trigger the SIGSEGV.  The values of the structure are
> set in line 350[3] and are OK there.  The funktion that contains the
> failing line is action() [4] and called via a pointer to this function
> in line 563[5] (I admit I have no real idea why this pointer to a
> function should be needed.  Its the only function that is used in this
> place and IMHO only adds an extra layer of complexity.)
>
> The structure is declared in the header file[6].
>
> I admit I fail to see why the code works under stretch with gcc 6.3
> but fails with gcc 8.2.
>
> Any idea?
>
> Kind regards
>
>Andreas.
>
>
> [1] https://github.com/soedinglab/ffindex_soedinglab/issues/7
> [2] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L554
> [3] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L350
> [4] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L541
> [5] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L563
> [6] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.h#L30

Bug#917570: marked as done (RFS: nautilus-hide/0.2.3-6)

[Debian Bug Tracking System]

Your message dated Wed, 09 Jan 2019 16:19:53 -0500
with message-id 
and subject line Re: RFS: nautilus-hide/0.2.3-6
has caused the Debian Bug report #917570,
regarding RFS: nautilus-hide/0.2.3-6
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
917570: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917570
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "nautilus-hide"

 * Package name: nautilus-hide
   Version : 0.2.3-6
   Upstream Author : Bruno Nova 
 * URL : https://github.com/brunonova/nautilus-hide
 * License : GPL-3+
   Section : gnome

  It builds this binary package:

nautilus-hide - Extension for Nautilus to hide files without renaming them

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/nautilus-hide


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/n/nautilus-hide/nautilus-hide_0.2.3-6.dsc

  Changes since the last upload:

  * Cherry-pick unreleased upstream fix for "RuntimeError: object
at 0x... of type NautilusHide is not initialized".
  * Simplify process by which mutable files are backed up and restored.
  * Indicate compliance with Debian Policy 4.3.0 (no changes required).


  Regards,
   Carlos Maddela
--- End Message ---
--- Begin Message ---
Uploaded.

--
Regards,
Boyuan Yang


signature.asc
Description: This is a digitally signed message part
--- End Message ---

Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Andrey Rahmatullin]

On Wed, Jan 09, 2019 at 09:42:43PM +0100, Andreas Tille wrote:
> to find the exact code line[2] where the SIGSEGV is thrown.  It turns out
> that the elements of a structure are not accessible:
> 
>(gdb) print entry->offset
>Cannot access memory at address 0x7
It's because entry is 0x7.

> In fact I tried in some more detailed debugging that any attempt to
> access one of the structure elements even for instance only injecting
> something like 
> 
>if ( !entry->offset ) {
Of course this won't work, entry is 0x7.

> The values of the structure are set in line 350[3] and are OK there.
The problem is not about the structure fields but about the structure
pointer itself though.

> The funktion that contains the failing line is action() [4] and called
> via a pointer to this function in line 563[5] (I admit I have no real
> idea why this pointer to a function should be needed.  Its the only
> function that is used in this place and IMHO only adds an extra layer of
> complexity.)
No? line 563 calls twalkmisc() which walks the tree and calls action() for
each node. 

You need to find out why one of the tree nodes has an invalid address.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Andreas Tille]

Hi,

as reported in bug #907624 ffindex autopkgtest fails with SIGSEGV in sid
and buster.  I've tested in stretch (gcc 6.3) and the code works fine.
I've reported upstream[1] the results of my gdb session where I was able
to find the exact code line[2] where the SIGSEGV is thrown.  It turns out
that the elements of a structure are not accessible:

   (gdb) print entry->offset
   Cannot access memory at address 0x7

(full gdb log under [1] or in the bug log).

In fact I tried in some more detailed debugging that any attempt to
access one of the structure elements even for instance only injecting
something like 

   if ( !entry->offset ) {

in line 554 will trigger the SIGSEGV.  The values of the structure are
set in line 350[3] and are OK there.  The funktion that contains the
failing line is action() [4] and called via a pointer to this function
in line 563[5] (I admit I have no real idea why this pointer to a
function should be needed.  Its the only function that is used in this
place and IMHO only adds an extra layer of complexity.)

The structure is declared in the header file[6].

I admit I fail to see why the code works under stretch with gcc 6.3
but fails with gcc 8.2.

Any idea?

Kind regards

   Andreas.


[1] https://github.com/soedinglab/ffindex_soedinglab/issues/7
[2] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L554
[3] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L350
[4] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L541
[5] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L563
[6] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.h#L30

-- 
http://fam-tille.de

Re: ITP: sexpect -- Expect for Shells

[Andrey Rahmatullin]

On Wed, Jan 09, 2019 at 09:43:08PM +0800, Clark Wang wrote:
> I filed an ITP bug for my own project (https://github.com/clarkwang/sexpect)
> at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=91 . I'm not quite
> sure what I can do next. Can someone help me out?
https://mentors.debian.net/intro-maintainers

-- 
WBR, wRAR


signature.asc
Description: PGP signature

ITP: sexpect -- Expect for Shells

[Clark Wang]

Hi,

I filed an ITP bug for my own project (https://github.com/clarkwang/sexpect)
at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=91 . I'm not quite
sure what I can do next. Can someone help me out?

-clark