Ah good, it's the same with older libc so qsort isn't implicated.
On 2017/06/03 19:54, Bryan Linton wrote:
> On 2017-06-03 10:59:17, Stuart Henderson <stu@spacehopper.org> wrote:
> > On 2017/06/03 17:59, Bryan Linton wrote:
> > > On 2017-06-03 09:23:18, Stuart Henderson <stu@spacehopper.org> wrote:
> > > > On 2017/06/03 15:50, Bryan Linton wrote:
> > > > >
> > > > > Ping? No users of ispell here?
> > > > >
> > > >
> > > > It works here, can you build with symbols (make clean && make repackage
> > > > DEBUG=-g) and get a backtrace?
> > > >
> > >
> > > Sure, here it is, along with some more information that may be relevant.
> > >
> > > % ispell
> > > ispell(84800) in free(): bogus pointer (double free?) 0x687361
> > > zsh: abort (core dumped) ispell
> >
> > > #2 0x000019945ba50566 in wrterror (d=0x7f7ffffea720,
> > > msg=0x19945bb82168 "bogus pointer (double free?) %p")
> > > at /usr/src/lib/libc/stdlib/malloc.c:306
> > > #3 0x000019945ba51c8d in ofree (argpool=0x19946bab8c60, p=0x687361, clear=0,
> > > check=0, argsz=0) at /usr/src/lib/libc/stdlib/malloc.c:1411
> > > #4 0x000019945ba51f03 in free (ptr=0x687361)
> > > at /usr/src/lib/libc/stdlib/malloc.c:1444
> > > #5 0x00001991e3c07711 in init_keyword_table (rawtags=Variable "rawtags" is not available.
> > > ) at defmt.c:1316
> > > #6 0x00001991e3c01a66 in main (argc=0, argv=0x7f7ffffebb30) at ispell.c:889
> >
> > 0x687361 (keywordbuf) seems unlikely to be a correct address and the
> > fact that it's a representation of ascii chars "ash" seems like it could
> > be more than a coincidence.
> >
> > It would be really nice to be able to replicate this, let's try to
> > figure out what's different about your setup.
> >
> > Do you have any .ispell* files?
> >
>
> Yes, however mv'ing them away does not change the behavior. But
> see below.
>
> > Do you have any of the other dictionary packages (ispell-dutch,
> > ispell-french, etc) installed?
> >
>
> % pkg_info -a | grep ispell
> ispell-3.2.06p9 interactive spelling checker
> %
>
> > Does it happen with a clean environment ("env -i ispell") as well?
> > If not, what's in your usual environment?
> >
>
> "env -i ispell" works just fine for me, so I did some digging.
>
> % env | grep ispell
> DICTIONARY=/usr/local/lib/ispell/american.hash
> % ispell
> ispell(4541) in free(): bogus pointer (double free?) 0x687361
> zsh: abort (core dumped) ispell
> % DICTIONARY=/usr/local/lib/ispell/british.hash
> % ispell
> ispell(22859) in free(): bogus pointer (double free?) 0x6873
> zsh: abort (core dumped) ispell
> % DICTIONARY=/usr/local/lib/ispell/default.hash
> % ispell
> ispell(87738) in free(): bogus pointer (double free?) 0x6873
> zsh: abort (core dumped) ispell
> % DICTIONARY=/usr/local/lib/ispell/americanmed+.hash
> % ispell
> ispell(57185) in free(): bogus pointer (double free?) 0x68736168002b64
> zsh: abort (core dumped) ispell
>
> 0x68736168002b64 would appear to be "hsah<NUL>+d" when read
> forwards and "d+<NUL>hash" when read backwards.
yep - if it's treated as a memory address on a little-endian machine
it would be backwards.
> It would appear that the hash files are somehow causing this
> behavior. Also, to reiterate, when ispell is compiled with clang,
> this crash does not happen. I'm not sure what clang might be
> doing differently, but I figure it might be pertinent information
> to have.
different optimization decisions, different memory layout in the
compiled code, various possibilities..
> Hopefully this will allow you to duplicate this behavior. If not,
> please let me know what else I can do to help.
It does, thanks. I see the same if I update it to 3.4.00 (I've updated
the port anyway as that was overdue).
I don't see where keywordbuf is intentionally getting set to anything
other than a fresh malloc though, and don't know where to start looking
to find something else that might be scribbling over it.
Simple replication of the problem: just run
DICTIONARY=/usr/local/lib/ispell/american.hash ispell
No comments:
Post a Comment