#121 aspell dumps core on czech word list

[Thomas Klausner]

I saw this on NetBSD-2.0/i386 in 0.60.1.1 with
aspell6-cs-20040614-1, and the problem is still there
in 0.60.2.

During the building of the czech dictionary, aspell
dumps core:
Finding Dictionary file location ...
/usr/pkg/lib/aspell

Finding Data file location ... /usr/pkg/share/aspell

===> Building for aspell-czech-20040614.1

/usr/pkg/bin/prezip-bin -d < cs.cwl |
/usr/pkg/bin/aspell --lang=cs create master ./cs.rws

[1] Done /usr/pkg/bin/pre... |

Segmentation fault (core dumped)
/usr/pkg/bin/asp...

*** Error code 139

The backtrace looks like this:
gdb /usr/pkg/bin/aspell
work/aspell6-cs-20040614-1/aspell.core

GNU gdb 5.3nb1

Copyright 2002 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--netbsdelf"...(no
debugging symbols found)...

Core was generated by `aspell'.

Program terminated with signal 11, Segmentation fault.

Reading symbols from /usr/libexec/ld.elf_so...(no
debugging symbols found)...done.

Loaded symbols for /usr/libexec/ld.elf_so

Reading symbols from /usr/pkg/lib/libaspell.so.15...(no
debugging symbols found)...done.

Loaded symbols for /usr/pkg/lib/libaspell.so.15

Reading symbols from /usr/lib/libpthread.so.0...(no
debugging symbols found)...done.

Loaded symbols for /usr/lib/libpthread.so.0

Reading symbols from /usr/lib/libcurses.so.6...(no
debugging symbols found)...done.

Loaded symbols for /usr/lib/libcurses.so.6

Reading symbols from /usr/lib/libstdc++.so.5...(no
debugging symbols found)...done.

Loaded symbols for /usr/lib/libstdc++.so.5

Reading symbols from /usr/lib/libm387.so.0...(no
debugging symbols found)...done.

Loaded symbols for /usr/lib/libm387.so.0

Reading symbols from /usr/lib/libm.so.0...(no debugging
symbols found)...done.

Loaded symbols for /usr/lib/libm.so.0

Reading symbols from /usr/lib/libgcc_s.so.1...(no
debugging symbols found)...done.

Loaded symbols for /usr/lib/libgcc_s.so.1

Reading symbols from /usr/lib/libc.so.12...(no
debugging symbols found)...done.

Loaded symbols for /usr/lib/libc.so.12

#0 0x48295112 in memchr () from /usr/lib/libc.so.12

(gdb) bt

#0 0x48295112 in memchr () from /usr/lib/libc.so.12

#1 0x08bd0ffc in ?? ()

#2 0x480d86ce in
aspeller::create_default_readonly_dict(acommon::StringEnumeration*,
acommon::Config&) ()
from /usr/pkg/lib/libaspell.so.15

#3 0x08058642 in aspeller::WordListIterator::adv() ()

#4 0x0804e803 in aspeller::WordListIterator::adv() ()

#5 0x0804d342 in aspeller::WordListIterator::adv() ()

With debugging symbols I get:
(gdb) bt

#0 0x48320112 in memchr () from /usr/lib/libc.so.12

#1 0xbfbfeab0 in ?? ()

#2 0x48133e9e in
aspeller::create_default_readonly_dict(acommon::StringEnumeration*,
acommon::Config&) (els=0x807a1c0,
config=@0x8074000) at
modules/speller/default/readonly_ws.cpp:1155

#3 0x0805a88f in master() () at prog/aspell.cpp:1490

#4 0x08053e98 in main (argc=5, argv=0xbfbfeb1c) at
prog/aspell.cpp:451

#5 0x08052922 in ___start ()

(gdb) fr 2

#2 0x48133e9e in
aspeller::create_default_readonly_dict(acommon::StringEnumeration*,
acommon::Config&) (els=0x807a1c0,
config=@0x8074000) at
modules/speller/default/readonly_ws.cpp:1155

1155 RET_ON_ERR(create(els,*lang,config));

(gdb) p els

$1 = (StringEnumeration *) 0x807a1c0

(gdb) p lang

$2 = {ptr = 0x807b000}

(gdb) p config

$3 = (class Config &) @0x8074000: {<CanHaveError> =
{_vptr.CanHaveError = 0x481ae298, err_ = {impl = {ptr_
= 0x0,
parms_ = {<No data fields>}}}}, static
num_parms_ = {1, 1, 0, 0, 0, 1, 1, 1, 0}, name_ =
{<OStream> = {
_vptr.OStream = 0x8071078}, begin_ = 0x8073040
"aspell", end_ = 0x8073046 "", storage_end_ = 0x8073047
"",
static npos = 2147483647}, first_ = 0x807a800,
insert_point_ = 0x807a900, others_ = 0x0, committed_ =
true,
attached_ = false,

notifier_list =
{<vector<acommon::Notifier*,std::allocator<acommon::Notifier*>
>> =
{<_Vector_base<acommon::Notifier*,std::allocator<acommon::Notifier*>
>> =

{<_Vector_alloc_base<acommon::Notifier*,std::allocator<acommon::Notifier*>,true>>
= {
_M_start = 0x8076000, _M_finish = 0x8076004,

_M_end_of_storage = 0x8076004}, <No data
fields>}, <No data fields>}, <No data fields>},
keyinfo_begin = 0x481ae300,
keyinfo_end = 0x481ae9a8, extra_begin = 0x0,
extra_end = 0x0, md_info_list_index = -1,
settings_read_in_ = true,
temp_str = {<OStream> = {_vptr.OStream = 0x8071078},
begin_ = 0x0, end_ = 0x0, storage_end_ = 0x0, static
npos = 2147483647},
load_filter_hook = 0, filter_mode_notifier =
0x8073050,

filter_modules =
{<vector<acommon::ConfigModule,std::allocator<acommon::ConfigModule>
>> =
{<_Vector_base<acommon::ConfigModule,std::allocator<acommon::ConfigModule>
>> =
{<_Vector_alloc_base<acommon::ConfigModule,std::allocator<acommon::ConfigModule>,true>>
= {_M_start = 0x8075000, _M_finish =
0x80750a0,

_M_end_of_storage = 0x80750a0}, <No data
fields>}, <No data fields>}, <No data fields>},

filter_modules_ptrs =
{<vector<acommon::Cacheable*,std::allocator<acommon::Cacheable*>
>> =
{<_Vector_base<acommon::Cacheable*,std::allocator<acommon::Cacheable*>
>> =
{<_Vector_alloc_base<acommon::Cacheable*,std::allocator<acommon::Cacheable*>,true>>
= {
_M_start = 0x0, _M_finish = 0x0,
_M_end_of_storage = 0x0}, <No data fields>}, <No data
fields>}, <No data fields>}}
(gdb) p *els

warning: can't find class named
`acommon::StringEnumeration', as given by C++ RTTI

$4 = {_vptr.StringEnumeration = 0x806b3c8, ref_count_ =
0, type_id_ = {num = 0, str = "\0\0\0"}, copyable_ = 2,

temp_str = {<OStream> = {_vptr.OStream = 0x806b408},
begin_ = 0x0, end_ = 0x0, storage_end_ = 0x0, static
npos = 2147483647},
from_internal_ = 0x0}

I suspect one of the memchr arguments to be NULL,
but haven't tracked it down yet.

[Kevin Atkinson]

Logged In: YES
user_id=6591

I can't reproduce the problem but Valgrind did detect a
problem. The following patch fixes the problem valgrind
detected. Let me know if it solves your problem.

If you don't respond within 2 weeks I will close the bug,
assuming its fixed.

[Kevin Atkinson]

[Thomas Klausner]

Logged In: YES
user_id=205695

Yes, the patch fixes the problem.
Thanks for tracking it down!

[Kevin Atkinson]

Logged In: YES
user_id=6591

Thanks for the Info. I am closing this bug now. Sorry it
took so long to fix.