Luca Ferrari <fluca1...@gmail.com> writes:
> On Tue, Oct 12, 2021 at 10:31 AM Omar Polo <o...@omarpolo.com> wrote: >> readline from ports shouldn't be needed. Moreover, port's readline >> install files as `libereadline', so it should be difficult to pick those >> header by accident. > > Since I'm curious, what if a program needs newer readline? It will > need libereadline therefore in the headers, right? > > >> # pkg_add gdb >> $ egdb $(which pspg) pspg.core > > seems the same stack trace to me (I produced a new core file): > > puffy# egdb $(which pspg) pspg.core > GNU gdb (GDB) 7.12.1 > Copyright (C) 2017 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-unknown-openbsd6.9". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from /usr/local/bin/pspg...done. > [New process 557312] > Core was generated by `pspg'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x0000000000000000 in ?? () > (gdb) bt > #0 0x0000000000000000 in ?? () > #1 0x00000bd4557bf1b6 in _rl_callback_newline () at > /usr/src/gnu/lib/libreadline/callback.c:75 > #2 rl_callback_handler_install (prompt=<optimized out>, > linefunc=0xbd162b99b50 <readline_callback>) at > /usr/src/gnu/lib/libreadline/callback.c:93 > #3 0x00000bd162b996b4 in get_string (prompt=0xbd162b68c53 "/", > buffer=0x7f7ffffe4e30 "\t", maxsize=255, > defstr=0xbd162bac860 <last_row_search> "", > _tabcomplete_mode=<optimized out>) at src/readline.c:588 > #4 0x00000bd162b8a2d8 in main (argc=0, argv=0x1) at src/pspg.c:5405 (I'm curios why you have argc=0 argv=0x1 here) > Any other thing I can do to better diagnose the problem? > > Thanks, > Luca I get a slightly different backtrace (gdb) bt #0 0x0000000000000000 in ?? () #1 0x000006a3e36026a6 in _rl_callback_newline () at /usr/src/gnu/lib/libreadline/callback.c:75 #2 rl_callback_handler_install ( prompt=<error reading variable: Unhandled dwarf expression opcode 0xa3>, linefunc=0x6a1332681c0 <readline_callback>) at /usr/src/gnu/lib/libreadline/callback.c:93 #3 0x000006a133267db1 in get_string (prompt=0x6a133236534 "/", buffer=0x7f7ffffdf240 "\001\023\376\377\177\177", maxsize=255, defstr=0x6a13327b470 <last_row_search> "", _tabcomplete_mode=117 'u') at src/readline.c:588 #4 0x000006a133259234 in main (argc=<optimized out>, argv=<optimized out>) at src/pspg.c:5405 (gdb) f 1 #1 0x000006a3e36026a6 in _rl_callback_newline () at /usr/src/gnu/lib/libreadline/callback.c:75 75 (*rl_prep_term_function) (_rl_meta_flag); (gdb) p rl_prep_term_function $1 = (rl_vintfunc_t *) 0x0 and here's the reason of the crash: rl_prep_term_function is NULL. % grep rl_prep_term_function . -RinH ./src/readline.c:786: rl_prep_term_function = NULL; they seem to set that function to NULL explicitly. Even patching that out, it still crashes, so I think following sthen@ advice and use readline from ports with $ ./configure CFLAGS=-I/usr/local/include/ereadline \ LDFLAGS='-L/usr/local/lib -lereadline' then from some quick tests seems to work! btw, it would be nice to have it in the port tree. I might do it sometimes in the following days if someone doesn't beat me ;)
