Bug#889608: Continuing to get core dumps with man-db

[Colin Watson]

On Wed, Feb 28, 2018 at 10:09:29PM -0500, John Sivak wrote:
> We have a winner. That build works on my system as well.

Great.  In that case, 2.8.2 contains that fix.

Thanks!

-- 
Colin Watson   [cjwat...@debian.org]

Bug#889608: Continuing to get core dumps with man-db

[John Sivak]

We have a winner. That build works on my system as well.

Let me know if you need any other assistance and thanks for tracking
down the issue.

John

On 02/28/2018 08:13 AM, Colin Watson wrote:
> On Sun, Feb 25, 2018 at 07:13:52PM -0500, John Sivak wrote:
>> On 02/25/2018 07:06 AM, Colin Watson wrote:
>>> Ah, right, no explicit path there. Can you try git master again
>>> (https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=122802046452c5d900a3d74b643d2089c4df58d2)?
>> Still not working. :(
>>
>> Stack trace attached for: strace -f -o man.trace -s 1024 man man
> OK, I finally cracked and installed a trial setup in a VM so that I
> could iterate more quickly.
> https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=eb88d394e8c3bed3953bbeb106f0dc5996c18621
> now works for me - please confirm.
>
> Thanks,
>

Bug#889608: Continuing to get core dumps with man-db

[Colin Watson]

On Sun, Feb 25, 2018 at 07:13:52PM -0500, John Sivak wrote:
> On 02/25/2018 07:06 AM, Colin Watson wrote:
> > Ah, right, no explicit path there. Can you try git master again
> > (https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=122802046452c5d900a3d74b643d2089c4df58d2)?
> 
> Still not working. :(
> 
> Stack trace attached for: strace -f -o man.trace -s 1024 man man

OK, I finally cracked and installed a trial setup in a VM so that I
could iterate more quickly.
https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=eb88d394e8c3bed3953bbeb106f0dc5996c18621
now works for me - please confirm.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#889608: Continuing to get core dumps with man-db

[John Sivak]

On 02/25/2018 07:13 PM, John Sivak wrote:
> On 02/25/2018 07:06 AM, Colin Watson wrote:
>> Ah, right, no explicit path there. Can you try git master again
>> (https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=122802046452c5d900a3d74b643d2089c4df58d2)?
>>
> Still not working. :(
>
> Stack trace attached for: strace -f -o man.trace -s 1024 man man
>
> John
>
To add details as to how I'm building/compiling the code; I'm using the
Arch build system to build the man-db package:

PKGBUILD script:


# $Id$
# Maintainer: Andreas Radke 
# Contributor: Sergej Pupykin 

pkgname=man-db
pkgver=122802046452c5d900a3d74b643d2089c4df58d2
pkgrel=1
pkgdesc="A utility for reading man pages"
arch=('x86_64')
url="http://www.nongnu.org/man-db/;
license=('GPL' 'LGPL')
groups=('base')
depends=( 'bash' 'gdbm' 'zlib' 'groff' 'libpipeline' 'less' 'libseccomp')
makedepends=('po4a')
optdepends=('gzip')
backup=('etc/man_db.conf')
conflicts=('man')
provides=('man')
replaces=('man')
install=${pkgname}.install
source=(#https://download-mirror.savannah.gnu.org/releases/man-db/$pkgname-$pkgver.tar.xz{,.sig}
   
#https://savannah.nongnu.org/download/man-db/$pkgname-$pkgver.tar.xz{,.asc}
   
https://git.savannah.gnu.org/cgit/man-db.git/snapshot/man-db-122802046452c5d900a3d74b643d2089c4df58d2.tar.gz
    convert-mans
    man-db.{timer,service})
validpgpkeys=('AC0A4FF12611B6FCCF01C111393587D97D86500B') # Colin Watson

sha512sums=('e6f10b19d6efef065b8005861a07ea752874f3c973e7470deb344ef3013404a5187ef48a1dbe01661541eda5718becd21b80295e3ee01954e2587ef4c65cf306'
   
'0b159285da20008f0fc0afb21f1eaebd39e8df5b0594880aa0e8a913b656608b8d16bb8d279d9e62d7aae52f62cb9b2fc49e237c6711f4a5170972b38d345535'
   
'2ed529500fbe18ba00ac7a6fc4c9da59e396464afb256db33f462b1127e497916602370e65e485c8d788c839f5b1b1130028502f61e1cc9ec8571ad6dd993738'
   
'76f8d51866418b612a72deaf3b07134d416a6d014dd3883fa78e08683c6b08553f483a4384ac87da25ac9896faa4807842fc69c42950cefe3c1c0590883aa600')

build() {
  cd ${pkgname}-${pkgver}
  ./configure --prefix=/usr \
    --sbindir=/usr/bin \
    --sysconfdir=/etc \
    --libexecdir=/usr/lib \
    --with-db=gdbm \
    --disable-setuid \
    --enable-cache-owner=root \
    --enable-mandirs=GNU \
    --with-sections="1 n l 8 3 0 2 5 4 9 6 7"
  make
}

check() {
  cd ${pkgname}-${pkgver}
  #make check
}

package() {
  cd ${pkgname}-${pkgver}
  make DESTDIR=${pkgdir} install

  # part of groff pkg
  rm -f ${pkgdir}/usr/bin/zsoelim

  # script from LFS to convert manpages, see
  # http://www.linuxfromscratch.org/lfs/view/6.4/chapter06/man-db.html
  install -D -m755 ${srcdir}/convert-mans  ${pkgdir}/usr/bin/convert-mans

  # install man-db update timer
  install -D -m644 ${srcdir}/man-db.timer
${pkgdir}/usr/lib/systemd/system/man-db.timer
  install -D -m644 ${srcdir}/man-db.service
${pkgdir}/usr/lib/systemd/system/man-db.service
  install -d -m755 ${pkgdir}/usr/lib/systemd/system/multi-user.target.wants
  ln -s ../man-db.timer
${pkgdir}//usr/lib/systemd/system/multi-user.target.wants/man-db.timer
}

Bug#889608: Continuing to get core dumps with man-db

[Colin Watson]

On Tue, Feb 20, 2018 at 10:31:01PM -0500, John Sivak wrote:
> Here is the contents of LD_PRELOAD and /etc/ld.so.preload:
> 
> /home/jsivak $ echo $LD_PRELOAD
> 
> /home/jsivak $ cat /etc/ld.so.preload
> libesets_pac.so

Ah, right, no explicit path there.  Can you try git master again
(https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=122802046452c5d900a3d74b643d2089c4df58d2)?

-- 
Colin Watson   [cjwat...@debian.org]

Bug#889608: Continuing to get core dumps with man-db

[Colin Watson]

On Mon, Feb 19, 2018 at 05:50:09PM -0500, John Sivak wrote:
> I can confirm that removing the ESET antivirus software eliminates the
> error with man.

I think I guessed wrongly as to how you had this antivirus hooked up.
Could you try git master again
(https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=b795a7a761b4331ccc0b3b4b0cea554d1c718236)?
If that still doesn't work, please tell me the value of the $LD_PRELOAD
environment variable (if any) and the contents of /etc/ld.so.preload.

> Also, I saw this text in the ESET user guide at
> https://download.eset.com/com/eset/apps/home/eav/linux/latest/eset_eav_lin_4_userguide_enu.pdf:
> 
> NOTE:  SELINUX  AND  APPARMOR  ARE  NOT  SUPPORTED.  THEY
> HAVE  TO  BE  DISABLED  PRIOR  TO  INSTALLING  ESET  NOD32
> ANTIVIRUS.
> 
> Let me know if you want to continue debugging this or close the issue
> since it seems to be caused by the ESET software.

It's worth noting that
http://download.eset.com/manuals/eset_file_security.pdf recommends
(5.3.2) that you should only configure LD_PRELOAD for a few selected
processes on your network boundary rather than for everything, and that
you shouldn't use /etc/ld.so.preload.  Still, I'd like to get this
working while I have your attention, since it seems quite close now.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#889608: Continuing to get core dumps with man-db

[John Sivak]

I can confirm that removing the ESET antivirus software eliminates the
error with man.

Also, I saw this text in the ESET user guide at
https://download.eset.com/com/eset/apps/home/eav/linux/latest/eset_eav_lin_4_userguide_enu.pdf:

NOTE:  SELINUX  AND  APPARMOR  ARE  NOT  SUPPORTED.  THEY
HAVE  TO  BE  DISABLED  PRIOR  TO  INSTALLING  ESET  NOD32
ANTIVIRUS.

Let me know if you want to continue debugging this or close the issue
since it seems to be caused by the ESET software.

Thanks for your help and assistance with this issue.

John

On 02/19/2018 05:34 PM, John Sivak wrote:
> On 02/19/2018 05:59 AM, Colin Watson wrote:
>> On Mon, Feb 19, 2018 at 10:15:47AM +, Colin Watson wrote:
>>> Do you have an unusual libc or a modified libpipeline or something?  The
>>> sequence of system calls that your trace shows at the point where
>>> libpipeline should be calling execvp for nroff doesn't correspond to any
>>> libc implementation I can find, and the failure comes when it tries to
>>> open a Unix-domain socket in the middle of the execvp sequence which is
>>> just weird.
>> Ah, you're using an antivirus program.  Do mention that in bug reports
>> in future, since I spent a non-trivial amount of time digging to find
>> this out!  Please try git master, which has this patch:
>>
>>   
>> https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=6ed6c9f92ab8f981aa1aa664f7e607bcd540ad44
>>
> Many apologies; hadn't thought about Antivirus being a factor.
>
> I've build the man-db package you linked to using the Archlinux package
> script and am still getting the error.
>
> New stack trace is attached.  I will also remove the ESET antivirus to
> see if that is causing the conflict as well.

Bug#889608: Continuing to get core dumps with man-db

[Colin Watson]

On Mon, Feb 19, 2018 at 10:15:47AM +, Colin Watson wrote:
> Do you have an unusual libc or a modified libpipeline or something?  The
> sequence of system calls that your trace shows at the point where
> libpipeline should be calling execvp for nroff doesn't correspond to any
> libc implementation I can find, and the failure comes when it tries to
> open a Unix-domain socket in the middle of the execvp sequence which is
> just weird.

Ah, you're using an antivirus program.  Do mention that in bug reports
in future, since I spent a non-trivial amount of time digging to find
this out!  Please try git master, which has this patch:

  
https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=6ed6c9f92ab8f981aa1aa664f7e607bcd540ad44

-- 
Colin Watson   [cjwat...@debian.org]

Bug#889608: Continuing to get core dumps with man-db

[Colin Watson]

On Sun, Feb 18, 2018 at 07:22:01PM -0500, John Sivak wrote:
> On 02/18/2018 04:50 PM, Colin Watson wrote:
> > Any information at all would be good. :-)  Could you start by running
> > the relevant man command line under "strace -f -o man.trace -s 1024" and
> > attaching the resulting man.trace file?
> 
> Attached is the trace for the command "strace -f -o man.trace -s 1024
> man man".

(For the record, this is entirely unrelated to the original report
#889608.)

Do you have an unusual libc or a modified libpipeline or something?  The
sequence of system calls that your trace shows at the point where
libpipeline should be calling execvp for nroff doesn't correspond to any
libc implementation I can find, and the failure comes when it tries to
open a Unix-domain socket in the middle of the execvp sequence which is
just weird.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#889608: Continuing to get core dumps with man-db

[Colin Watson]

On Sun, Feb 18, 2018 at 10:54:09AM -0500, John Sivak wrote:
> I am still getting core dumps when using "man".
> 
> Linux distribution: Archlinux
> man-db version: 2.8.1-1
> 
> Reference bug post in Archlinux bug tracker:
> https://bugs.archlinux.org/task/57436
> 
> Let me know what other information you'd like me to provide.

Any information at all would be good. :-)  Could you start by running
the relevant man command line under "strace -f -o man.trace -s 1024" and
attaching the resulting man.trace file?

-- 
Colin Watson   [cjwat...@debian.org]

Bug#889608: Continuing to get core dumps with man-db

[John Sivak]

I am still getting core dumps when using "man".

Linux distribution: Archlinux
man-db version: 2.8.1-1

Reference bug post in Archlinux bug tracker:
https://bugs.archlinux.org/task/57436

Let me know what other information you'd like me to provide.

Thank you.

John