[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#976102: a2ps 32-bit segfaults on startup




On 12/16/20 6:24 AM, Bernhard Übelacker wrote:
Am 15.12.20 um 23:00 schrieb Mack Stanley:
Dear Bernhard,

Thanks so much for your interest and your message.  I very recently realized that my bug report is in error and hoped that I would be able to correct or withdraw it before troubling anyone.

Here is how to reproduce the segfault I observed (in wither 32 or 64 bit debian a2ps):

Near the top of /etc/a2ps-site.cfg comment out one or both of the lines
_____

Options: --encoding=latin1
Options: --medium=libpaper
_____

Then just execute

a2ps

The result will be a crash with simply

Segmentation Fault

-------

I am very sorry to have filed a false bug report.  I had tried two 32 bit installations and one 64 bit.  Evidently I made the same mistake in both 32 bit installations: I must have installed with an old Fedora a2ps-site.cfg already in /etc/ , which the Debian installation politely refused to overwrite.  The default Fedora a2ps-site.cfg  has those two lines as

#Options: --encoding=latin1
Options: --medium=_glibc

After removing "#" from the first line, the debian build a2ps complains helpfully about the second line.  But with the "#" it just segfaults.

I am sorry it took me so long to find this mistake.  It wasn't till I built 32 bit a2ps from the GNU source that I saw the problem (http://ftp.gnu.org/gnu/a2ps/a2ps-4.14.tar.gz./configure --prefix=/usr --with-gnu-gettext --with-medium=letter ).

It would be nice if a2ps itself had been more forthcoming about my mistake rather than segfaulting.  But it was just that---my mistake.

Again, my apologies for wasting your time and my thanks for your interest.

Best regards, Mack



Hello Mack,
no problem, with these great details I could collect these backtraces:


    # With: #Options: --encoding=latin1

    (gdb) bt
    #0  __strlen_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:50
    #1  0x0050bfcc in strlower (string=0x0) at routines.c:95
    #2  0x005096cd in get_encoding_by_alias (job=0x57bc50, alias=0x0) at encoding.c:1207
    #3  0x0050aa50 in a2ps_job_finalize (job=0x57bc50) at jobs.c:305
    #4  0x004ef980 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1025
    (gdb)


    # With: #Options: --medium=libpaper

    (gdb) bt
    #0  __strcasecmp_l_sse4_2 () at ../sysdeps/i386/i686/multiarch/strcmp-sse4.S:229     #1  0x0050e22a in a2ps_get_medium (job=0xb1ec50, name=0x0) at media.c:164
    #2  0x0050ea6c in a2ps_job_finalize (job=0xb1ec50) at jobs.c:312
    #3  0x004f3980 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1025
    (gdb)


As you mentioned some relation to fedora I made a short
search and it looks like there are some patches used,
which are not yet upstreamed.

    https://src.fedoraproject.org/rpms/a2ps/tree/
    https://git.savannah.gnu.org/cgit/a2ps.git/log/

Especially the a2ps-4.13b-encoding.patch and
a2ps-4.13-glibcpaper.patch seem related.

Kind regards,
Bernhard



apt install systemd-coredump gdb a2ps a2ps-dbgsym
zcat /usr/share/doc/a2ps/README.gz | a2ps
coredumpctl list
coredumpctl gdb 2478

https://sources.debian.org/src/a2ps/1:4.14-5/lib/jobs.c/#L305


Dear Bernhard,


That's great news!


I do know that the build from the GNU a2ps tarball behaves like the Debian builds.  (I tried the Debian testing build too.) That's not surprising since it was the GNU stable source that I used.


The only other thing I know is that  Fedora 33's current build doesn't care whether "Options: --encoding=latin1" is commented out or not, but it does segfault if "Options: --medium=_glibc" is commented out in a2ps-site.cfg.  It doesn't segfault as long as it is passed "Options: --medium=..." where ... can be anything.  It will object that it doesn't know what "..". is, that is, if it is not "_glibc" or "letter" or "A4" or whatever, but it won't segfault.  Incidentally, it doesn't know what "libpaper" is.  And I don't know what "_glibc" is!


Thanks again for the positive news.

Best wishes, Mack


Reply to: