Re: ncurses 20170401 (+) SEGV gdb 7.12.1 in TUI mode on MinGW-w64

[Allen Hewes]

On 6/12/2017 5:40, Johann Klammer wrote:
> On 06/12/2017 04:11 AM, Allen Hewes wrote:
>> Thread 1 received signal SIGSEGV, Segmentation fault.
>> 0x00007ffcd179cdb8 in strncpy () from C:\WINDOWS\System32\msvcrt.dll
>> (gdb) bt full
>> #0  0x00007ffcd179cdb8 in strncpy () from C:\WINDOWS\System32\msvcrt.dll
>> No symbol table info available.
>> #1  0x0000000000742037 in set_curterm_sp (address@hidden, address@hidden)
>>     at ../../../../src/ncurses-6.0-20170401/ncurses/tinfo/lib_cur_term.c:110
>>         TCB = 0x169e7610
>>         oldterm = 0x0
>> #2  0x00000000007436fe in _nc_setupterm_ex (address@hidden, tname=<optimized 
>> out>, address@hidden, Filedes=1,
>>     address@hidden, address@hidden) at 
>> ../../../../src/ncurses-6.0-20170401/ncurses/tinfo/lib_setup.c:777
>>         TCB = 0x169e7610
>>         termp = 0x169e7610
>>         code = 0
>> #3  0x0000000000739ad1 in newterm_sp (sp=<optimized out>, address@hidden, 
>> address@hidden <msvcrt!_iob+48>,
>>     address@hidden <msvcrt!_iob>) at 
>> ../../../../src/ncurses-6.0-20170401/ncurses/base/lib_newterm.c:200
>>         errret = 0
>>         result = 0x0
>>         current = 0x0
>>         its_term = 0x0
>>         _ofp = 0x7ffcd17cf030 <msvcrt!_iob+48>
>>         _ifp = 0x7ffcd17cf000 <msvcrt!_iob>
>>         new_term = 0x169e7610
>> #4  0x0000000000739eb3 in newterm (address@hidden, ofp=0x7ffcd17cf030 
>> <msvcrt!_iob+48>,
>>     address@hidden <msvcrt!_iob>) at 
>> ../../../../src/ncurses-6.0-20170401/ncurses/base/lib_newterm.c:352
>>
>> Using the ncurses 20170325 release GDB 7.12.1 TUI mode works fine.
>>
>> Toolchain I build ncurses with:
>> mingw-w64 v5 (v5 branch)
>> binutils 2.28
>> gcc 6.3.1 (gcc-6-branch)
>> libsystre 1.0.1
>>
>> I don't where / how to do more troubleshooting. Any ideas would be great.
>>
> (gdb) frame 1
> list (or look at the line 110 in a text editor)
> look how the strncpy is called
> print the arguments
> so if it's strncpy(a,b,c)
> enter 
> (gdb) p a
> (gdb) p b
> (gdb) p c
>
> Look for NULL values in pointer variables (here a and b)
> or a missing string terminator.
>
> see where it comes from.
> ahead of the faulting line or
> if necessary searching up the call chain.
>
> (gdb) frame 2
> (gdb) frame 3
>
> etc...
Johann,

It's because termp.type.type_names is empty (0x0):

(gdb) break
../../../../src/ncurses-6.0-20170401/ncurses/tinfo/lib_cur_term.c:110

Breakpoint 1 at 0x748ed2: file
../../../../src/ncurses-6.0-20170401/ncurses/tinfo/lib_cur_term.c, line 110.
Thread 1 hit Breakpoint 1, set_curterm_sp (address@hidden,
address@hidden)
    at ../../../../src/ncurses-6.0-20170401/ncurses/tinfo/lib_cur_term.c:110
110             _nc_STRNCPY(ttytype, termp->type.term_names, MY_SIZE);

(gdb) set termp.type.term_names="#win32console"
(gdb) continue
Continuing.

I don't know enough of ncurses to know why the member
termp->type.term_names would be empty on Windows. But setting the
breakpoint and assigning a value does allow gdb --tui to run. I will
make a local patch to check gdb further.

On another note, I rebuilt ncurses with --with-trace and I didn't get
any output or a trace file. I set NCURSES_TRACE=1. I was expecting to
find a file called trace.log in the current directory.

Thanks,

/allen