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 <[email protected]> wrote: > > On 2017/06/03 17:59, Bryan Linton wrote: > > > On 2017-06-03 09:23:18, Stuart Henderson <[email protected]> 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
