Re: [code] [textadept] Possible bug?

From: Mitchell <>
Date: Tue, 8 May 2018 15:09:48 -0400 (EDT)

Hi James,

On Tue, 8 May 2018, triplejam wrote:

> Reading symbols from ./textadept...done.
> (gdb) set disable-randomization off
> (gdb) r
> Starting program: /home/james/Software/textadept_10.0_beta.x86_64/textadept
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/".
> [New Thread 0x7f0e5d86f700 (LWP 20113)]
> [New Thread 0x7f0e5d06e700 (LWP 20114)]
> Thread 1 "textadept" received signal SIGSEGV, Segmentation fault.
> 0x00007f0e5c1acc11 in ?? ()
> (gdb) bt
> #0 0x00007f0e5c1acc11 in ?? ()
> #1 0x00005570c16b83cb in luaD_precall (
> L=0x5570c2924108, func=0x5570c31cb3b0,
> nresults=1) at lua/src/ldo.c:434
> [snip]
> Is there something else to get more info?

Unfortunately, it looks like at this point the only way I can think to get more info would be to have you build your own module with debug symbols and then try to debug it. There may be a shortcut, but you'll certainly need to fetch the spellcheck source and put it in your ~/.textadept/modules/spellcheck/.

1. Download
2. Extract its contents into ~/.textadept/modules/spellcheck/
3. [Begin shortcut] Try running `gdb textadept`.
4. Before running the program, try putting a breakpoint `b ls_spell` and accept the "pending" query. This is the Lua `spell()` function that you determined was the entry point to the source of the crash.
5. Now run the program and trigger spell checking.
6. The debugger should break at lspell.cxx:22.
7. Type `n` for "next" twice.
8. There should be a crash after the second "next" (it should not get to line 24, the end of the function).
9. If the crash indeed happens, try and get the backtrace.
10. If the crash does not happen, then the crash is not happening in `spell()` and you'll have to do some more sleuthing.
11. [End shortcut] If you cannot break at `b ls_spell` in step 5, then you'll have to build your own
12. Run `make hunspell` and then `make CXX="g++ -g"`. Now try steps 3-11.

If you are still getting an unhelpful backtrace, and the crash is occuring inside hunspell, then you may be able to debug hunspell itself by putting a breakpoint `b Hunspell::spell` (hunspell.cxx:325) and rooting around there after continuing (`c`) from the `spell()` function breakpoint.

I am sorry for all the trouble you've been having, but I do very much appreciate your patience and taking the time to try and help me out.


You are subscribed to
To change subscription settings, send an e-mail to
To unsubscribe, send an e-mail to
Received on Tue 08 May 2018 - 15:09:48 EDT

This archive was generated by hypermail 2.2.0 : Wed 09 May 2018 - 06:32:29 EDT