Date: Thu, 21 Oct 2021 23:15:03 -0700 From: Mark Millard via freebsd-current <freebsd-current@freebsd.org> To: freebsd-current <freebsd-current@freebsd.org> Subject: Re: Is dialog4ports built in/for releng/13.0 also supposed to work under main [so: 14]? It gets SIGSEGV in my context. (some low level failure info now) Message-ID: <721F4836-0A36-4A8E-B596-5ED4BC02FC55@yahoo.com> In-Reply-To: <146075A5-1311-4C57-AD42-982C3FB5DF81@yahoo.com> References: <0465422C-DA30-4421-85E7-17CACBF0356D.ref@yahoo.com> <0465422C-DA30-4421-85E7-17CACBF0356D@yahoo.com> <20211021151438.7496a0d0@ernst.home> <DAAA6F08-521B-4764-BCF7-73828B4DF593@yahoo.com> <20211022002715.5a6ec66c7c27442f483e9347@dec.sakura.ne.jp> <E90E3F40-F408-4196-9C6F-9D3D9691794A@yahoo.com> <146075A5-1311-4C57-AD42-982C3FB5DF81@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Oct-21, at 16:24, Mark Millard <marklmi@yahoo.com> wrote:
> On 2021-Oct-21, at 11:53, Mark Millard <marklmi@yahoo.com> wrote:
>=20
>> On 2021-Oct-21, at 08:27, Tomoaki AOKI <junchoon at dec.sakura.ne.jp> =
wrote:
>>=20
>>> On Thu, 21 Oct 2021 07:40:36 -0700
>>> Mark Millard via freebsd-current <freebsd-current@freebsd.org> =
wrote:
>>>=20
>>>>=20
>>>>=20
>>>> On 2021-Oct-21, at 06:14, Gary Jennejohn <gljennjohn@gmail.com> =
wrote:
>>>>=20
>>>>> On Thu, 21 Oct 2021 01:34:47 -0700
>>>>> Mark Millard via freebsd-current <freebsd-current@freebsd.org> =
wrote:
>>>>>=20
>>>>>> I get the following crash (amd64 example shown), as reported
>>>>>> via gdb afterwards. (devel/llvm13 is just an example context.)
>>>>>>=20
>>>>>> gdb `which dialog4ports` devel/llvm13/dialog4ports.core
>>>>>> . . .
>>>>>> Core was generated by `/usr/local/bin/dialog4ports'.
>>>>>> Program terminated with signal SIGSEGV, Segmentation fault.
>>>>>> Address not mapped to object.
>>>>>> #0 vfprintf_l (fp=3D0x4d4940, locale=3D0x8004d4128 =
<__xlocale_global_locale>, fmt0=3D0x201f64 "\"%s\"", =
ap=3Dap@entry=3D0x7fffffffcf00) at =
/usr/main-src/lib/libc/stdio/vfprintf.c:281
>>>>>> 281 if ((fp->_flags & (__SNBF|__SWR|__SRW)) =3D=3D =
(__SNBF|__SWR) &&
>>>>>> (gdb) bt
>>>>>> #0 vfprintf_l (fp=3D0x4d4940, locale=3D0x8004d4128 =
<__xlocale_global_locale>, fmt0=3D0x201f64 "\"%s\"", =
ap=3Dap@entry=3D0x7fffffffcf00) at =
/usr/main-src/lib/libc/stdio/vfprintf.c:281
>>>>>> #1 0x0000000800409283 in fprintf (fp=3D0x800411660 =
<__stdio_cancel_cleanup>, fmt=3D0x7fffffffcdd0 "0\317\377\377\377\177") =
at /usr/main-src/lib/libc/stdio/fprintf.c:57
>>>>>> #2 0x000000000020399d in main (argc=3D<optimized out>, =
argv=3D<optimized out>) at dialog4ports.c:332
>>>>>> (gdb) quit
>>>>>>=20
>>>>>> The crash happens after selecting OK but not after selecting =
Cancel. The
>>>>>> display is also odd before that (no line drawing, just odd text =
instead),
>>>>>> but is sufficient to be usable at that stage.
>>>>>>=20
>>>>>> . . .
>>>>=20
>=20
> gdb's disass/s reports the failure point via:
>=20
> . . .
> /usr/main-src/lib/libc/stdio/vfprintf.c:
> 279 FLOCKFILE_CANCELSAFE(fp);
> 0x0000000800412357 <+71>: mov 0xbf082(%rip),%rax # =
0x8004d13e0
> 0x000000080041235e <+78>: cmpl $0x0,(%rax)
> 0x0000000800412361 <+81>: je 0x800412370 <vfprintf_l+96>
> 0x0000000800412363 <+83>: mov %rbx,%rdi
> 0x0000000800412366 <+86>: call 0x8004c6730 <_flockfile@plt>
> 0x000000080041236b <+91>: mov %rbx,%rsi
> 0x000000080041236e <+94>: jmp 0x800412372 <vfprintf_l+98>
> 0x0000000800412370 <+96>: xor %esi,%esi
> 0x0000000800412372 <+98>: lea -0xd19(%rip),%rdi # =
0x800411660 <__stdio_cancel_cleanup>
> 0x0000000800412379 <+105>: lea -0x70(%rbp),%rdx
> 0x000000080041237d <+109>: call 0x800384a90 =
<__pthread_cleanup_push_imp_int>
>=20
> 280 /* optimise fprintf(stderr) (and other unbuffered Unix =
files) */
> 281 if ((fp->_flags & (__SNBF|__SWR|__SRW)) =3D=3D =
(__SNBF|__SWR) &&
> =3D> 0x0000000800412382 <+114>: movzwl 0x10(%rbx),%eax
> 0x0000000800412386 <+118>: and $0x1a,%eax
> 0x0000000800412389 <+121>: cmp $0xa,%ax
> 0x000000080041238d <+125>: jne 0x8004123a9 <vfprintf_l+153>
>=20
> 282 fp->_file >=3D 0)
> 0x000000080041238f <+127>: cmpw $0x0,0x12(%rbx)
>=20
> 281 if ((fp->_flags & (__SNBF|__SWR|__SRW)) =3D=3D =
(__SNBF|__SWR) &&
> 0x0000000800412394 <+132>: js 0x8004123a9 <vfprintf_l+153>
> . . .
>=20
> (gdb) info reg
> rax 0x0 0
> rbx 0x4d4940 5065024
> rcx 0x7fffffffd0e0 140737488343264
> rdx 0x7fffffffcfb0 140737488342960
> rsi 0x0 0
> rdi 0x800411660 34364003936
> rbp 0x7fffffffd020 0x7fffffffd020
> rsp 0x7fffffffcfb0 0x7fffffffcfb0
> r8 0x0 0
> r9 0x0 0
> r10 0x800a330f0 34370433264
> r11 0x206 518
> r12 0x8004d4128 34364801320
> r13 0x2083a0 2130848
> r14 0x7fffffffd0e0 140737488343264
> r15 0x201f64 2105188
> rip 0x800412382 0x800412382 <vfprintf_l+114>
> eflags 0x10246 [ PF ZF IF RF ]
> cs 0x43 67
> ss 0x3b 59
> ds <unavailable>
> es <unavailable>
> fs <unavailable>
> gs <unavailable>
> fs_base <unavailable>
> gs_base <unavailable>
>=20
> where:
>=20
> (gdb) disass/s __pthread_cleanup_push_imp_int
> Dump of assembler code for function __pthread_cleanup_push_imp_int:
> /usr/main-src/lib/libc/gen/_pthread_stubs.c:
> 289 STUB_FUNC3(__pthread_cleanup_push_imp, PJT_CLEANUP_PUSH_IMP, =
void, void *,
> 0x0000000800384a90 <+0>: push %rbp
> 0x0000000800384a91 <+1>: mov %rsp,%rbp
> 0x0000000800384a94 <+4>: mov 0x14c94d(%rip),%rax # =
0x8004d13e8
> 0x0000000800384a9b <+11>: mov 0x3c8(%rax),%rax
> 0x0000000800384aa2 <+18>: pop %rbp
> 0x0000000800384aa3 <+19>: jmp *%rax
> End of assembler dump.
>=20
>=20
> It is not obvious that any of this has any relationship with
> libtinfow.so.9 or libncursesw.so.9 use unless some memory is
> being trashed first.
It is memory being stomped on, for example __stderrp has its value
inappropriately replaced by inappropriate code.
Hardware watchpoint 1: -location __stderrp
Old value =3D (FILE *) 0x8004d4940
New value =3D (FILE *) 0x4d4940
caused by:
0x00000008002d298e <+62>: movb $0x0,0x84(%rax)
of:
286 } else {
287 dialog_state.had_resize =3D FALSE;
in:
(gdb) bt
#0 0x00000008002d2995 in dlg_result_key (dialog_key=3D541, fkey=3D541, =
resultp=3Dresultp@entry=3D0x7fffffffd0c0) at =
/usr/main-src/contrib/dialog/dlg_keys.c:287
#1 0x0000000000204934 in dlg_mixedlist =
(title=3Dtitle@entry=3D0x7fffffffd150 " llvm13-13.0.0 ", =
cprompt=3D0x20207c "", height=3D<optimized out>, min_height=3D<optimized =
out>, width=3D<optimized out>,=20
width@entry=3D80, item_no=3D17, items=3D0x800a3dc80, =
align_center=3D<optimized out>, fullscreen=3D<optimized out>) at =
mixedlist.c:475
#2 0x000000000020393b in mixedlist_show (title=3D0x7fffffffd150 " =
llvm13-13.0.0 ", cprompt=3D<optimized out>, height=3D0, min_height=3D0, =
width=3D80, items=3D0x800a3dc80, align_center=3Dfalse, fullscreen=3Dfalse)=
at dialog4ports.c:212
#3 main (argc=3D<optimized out>, argv=3D<optimized out>) at =
dialog4ports.c:321
(gdb) disass/s
Dump of assembler code for function dlg_result_key:
/usr/main-src/contrib/dialog/dlg_keys.c:
278 {
0x00000008002d2950 <+0>: push %rbp
0x00000008002d2951 <+1>: mov %rsp,%rbp
0x00000008002d2954 <+4>: push %r15
0x00000008002d2956 <+6>: push %r14
0x00000008002d2958 <+8>: push %r12
0x00000008002d295a <+10>: push %rbx
0x00000008002d295b <+11>: mov %rdx,%r14
0x00000008002d295e <+14>: mov %esi,%r15d
0x00000008002d2961 <+17>: mov %edi,%ebx
279 int done =3D FALSE;
280=09
281 DLG_TRACE(("# dlg_result_key(dialog_key=3D%d, fkey=3D%d)\n", =
dialog_key, fkey));
0x00000008002d2963 <+19>: lea -0x116aa(%rip),%rdi # =
0x8002c12c0
0x00000008002d296a <+26>: xor %r12d,%r12d
0x00000008002d296d <+29>: mov %ebx,%esi
0x00000008002d296f <+31>: mov %r15d,%edx
0x00000008002d2972 <+34>: xor %eax,%eax
0x00000008002d2974 <+36>: call 0x8002ee460 <dlg_trace_msg@plt>
282 #ifdef KEY_RESIZE
283 if (dialog_state.had_resize) {
0x00000008002d2979 <+41>: mov 0x1ec10(%rip),%rax # =
0x8002f1590
0x00000008002d2980 <+48>: cmpb $0x0,0x84(%rax)
0x00000008002d2987 <+55>: je 0x8002d29dd <dlg_result_key+141>
284 if (dialog_key =3D=3D ERR) {
0x00000008002d2989 <+57>: cmp $0xffffffff,%ebx
0x00000008002d298c <+60>: je 0x8002d2998 <dlg_result_key+72>
285 dialog_key =3D 0;
286 } else {
287 dialog_state.had_resize =3D FALSE;
0x00000008002d298e <+62>: movb $0x0,0x84(%rax)
=3D> 0x00000008002d2995 <+69>: mov %ebx,%r12d
291 }
292 #endif
. . .
So: dialog_state.had_resize overlaps with the content of
__stderrp at the time, specifically with the most
significant byte of __stderrp .
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?721F4836-0A36-4A8E-B596-5ED4BC02FC55>