Bug 16198 - aspell coredumps
aspell coredumps
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: aspell (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-08-14 18:11 EDT by Jonathan Kamens
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-08-14 22:49:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
my installed packages (7.47 KB, text/plain)
2000-08-14 18:12 EDT, Jonathan Kamens
no flags Details

  None (edit)
Description Jonathan Kamens 2000-08-14 18:11:28 EDT
jik:/usr/src/redhat/BUILD/aspell-.32.1!141> aspell -a
Segmentation fault (core dumped)
jik:/usr/src/redhat/BUILD/aspell-.32.1!142> gdb aspell
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...(no debugging symbols
found)...
(gdb) run -a
Starting program: /usr/bin/aspell -a
(no debugging symbols found)...Cannot access memory at address 0x40016e38
(gdb) cont
Continuing.
Cannot access memory at address 0x40016e38
(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x4014c3ef in next_stack_level (pc=0x40068617, udata=0xbfffef30, 
    caller_udata=0xbfffefb0) at ../../gcc/libgcc2.c:3168
3168    ../../gcc/libgcc2.c: No such file or directory.
(gdb) where
#0  0x4014c3ef in next_stack_level (pc=0x40068617, udata=0xbfffef30, 
    caller_udata=0xbfffefb0) at ../../gcc/libgcc2.c:3168
#1  0x4014c644 in throw_helper (eh=0x40151880, pc=0x40068617,
my_udata=0xbffff070, 
    offset_p=0xbffff06c) at ../../gcc/libgcc2.c:3168
#2  0x4014c88a in __throw () at ../../gcc/libgcc2.c:3168
#3  0x400a38a2 in autil::ConfigData::throw_file_exception ()
   from /usr/lib/libaspell.so.7
#4  0x40068618 in aspell::Config::read_in () from /usr/lib/libaspell.so.7
#5  0x400684b1 in aspell::Config::read_in () from /usr/lib/libaspell.so.7
#6  0x40089d58 in aspell::Manager::setup () from /usr/lib/libaspell.so.7
#7  0x400890a8 in aspell::Manager::Manager () from /usr/lib/libaspell.so.7
#8  0x804f14b in aspell::new_default_readonly_word_set ()
#9  0x804d8a7 in aspell::new_default_readonly_word_set ()
#10 0x401d1665 in __libc_start_main (
    main=0x804cc60 <aspell::new_default_readonly_word_set(void)+496>,
argc=2, 
    ubp_av=0xbffff8a4, init=0x804c250 <_init>, fini=0x8060a70 <_fini>, 
    rtld_fini=0x4000dca4 <_dl_fini>, stack_end=0xbffff89c)
    at ../sysdeps/generic/libc-start.c:111

Then I tried rebuilding the aspell source RPM with "-g" so that I could
debug it further, but aspell crashes again while trying to build the master
dictionary during "rpm -bc".  I went through some convolutions to capture
this crash in gdb, and here's what I see:

(gdb) where
#0  0x4014c3ef in next_stack_level (pc=0x40061647, udata=0xbffff220, 
    caller_udata=0xbffff2a0) at ../../gcc/libgcc2.c:3168
#1  0x4014c644 in throw_helper (eh=0x40151880, pc=0x40061647, 
    my_udata=0xbffff360, offset_p=0xbffff35c) at ../../gcc/libgcc2.c:3168
#2  0x4014c88a in __throw () at ../../gcc/libgcc2.c:3168
#3  0x4009c8d2 in autil::ConfigData::throw_file_exception (this=0xbffff5b0, 
    file=0x80670e8 "/home/jik/.aspell.conf") at config_data.cc:30
#4  0x40061648 in aspell::Config::read_in (this=0xbffff6f0,
override=0x80661e0)
    at /usr/include/g++-3/std/bastring.h:343
#5  0x400614e1 in aspell::Config::read_in (this=0xbffff6f0,
override=0x80661e0)
    at config.cc:22
#6  0x80556e5 in master () at aspell.cc:927
#7  0x804dd77 in main (argc=5, argv=0xbffff964) at aspell.cc:302
#8  0x401d1665 in __libc_start_main (main=0x804cc90 <main>, argc=5, 
    ubp_av=0xbffff964, init=0x804c27c <_init>, fini=0x8060aa0 <_fini>, 
    rtld_fini=0x4000dca4 <_dl_fini>, stack_end=0xbffff95c)
    at ../sysdeps/generic/libc-start.c:111
(gdb) 

Note that I have not fully upgraded to Pinstripe; I have a mixture of 6.2,
Raw Hide and Pinstripe RPMs installed. I'll attach a full list of
everything I've got installed, in case it's relevant.

I can't debug this any further; I don't know enough C++ to figure out where
to go at this point.  If you have any suggestions, I'm all ears.  In the
meantime, I'm going to switch Emacs back to using ispell.
Comment 1 Jonathan Kamens 2000-08-14 18:12:17 EDT
Created attachment 2483 [details]
my installed packages
Comment 2 Trond Eivind Glomsrxd 2000-08-14 18:12:53 EDT
This should be fixed in the rawhide RPMs.
Comment 3 Jonathan Kamens 2000-08-14 18:17:02 EDT
Which Raw Hide RPMs in particular?  The aspell and pspell RPMS I see in
/pub/rawhide/i386/RedHat/RPMS on ftp.beta.redhat.com are not newer than what I
have installed.
Comment 4 Trond Eivind Glomsrxd 2000-08-14 22:33:58 EDT
I have all the latest ones.... and aspell -a works fine.
Comment 5 Jonathan Kamens 2000-08-14 22:49:11 EDT
You cannot reasonably conclude from the mere fact that it works for you that the
bug has already been fixed.  It is equally likely that there is simply something
in your environment that is different from my environment, such that aspell
works for you but coredumps for me.  That doesn't mean there's a bug in my
environment; it means that there's a bug in aspell for not handling my
environment properly.

Please spend some time debugging the stack trace I submitted, or suggesting how
I might do so, before informing me that there is no bug simply because it works
for you.

Please see the messages on the testers-list which indicate that other people
have had the problems I am having.

Please also tell me specifically what "latest ones" you have so that I can
compare them to mine.  If you don't provide me with that information, then there
is no way for me to even begin to consider the possibility that there is a newer
version of the aspell and pspell RPMS which solves the problem.

Do you have a .aspell.conf file in your home directory?  What is in it?  I
don't, and this file (or its absence) seems related to this coredump.

Also, I want to echo the major irritation expressed in previous bug reports
about aspell that it has no man page.

This package, i.e., aspell, is clearly quite simply Not Ready For Prime Time.  I
cannot fathom why Red Hat has chosen to replace a mature, working package such
as ispell with an immature, sloppy, non-working package such as aspell.  Offer
aspell as an option in Powertools?  Fine.  But replace ispell?  No way.  This is
just wrong.

One final comment.... Aspell doesn't core dump when I run it without any
options, so I got to see "Aspell .32.1 alpha".  Even the author admits that this
is ALPHA QUALITY CODE.  Why in God's name is Red Hat shipping it?
Comment 6 Trond Eivind Glomsrxd 2000-08-14 22:58:25 EDT
You say you have not fully upgraded to pinstripe - the ones in pinstripe had a
problem.
Note that is its very picky that you have correct versions of all libraries
(don't we all love C+...)

If considering to reopen, upgrade _completely_ to RC1. Or rebuild the SRPMS of
pspell (first) and aspell (second, after installing pspell and uninstalling
previous releases of aspell).

As for ispell, it's dead code that hasn't been maintained for ages, _didn't work
at all with the new compiler & glibc as it had hardly heard of the ANSI
standard_ and had tons of patches to try make it work and compile. RIP.


Note You need to log in before you can comment on or make changes to this bug.