* strlen-avx2.S
@ 2024-06-18 5:33 David Newall
2024-06-18 18:38 ` strlen-avx2.S Adhemerval Zanella Netto
0 siblings, 1 reply; 3+ messages in thread
From: David Newall @ 2024-06-18 5:33 UTC (permalink / raw)
To: libc-help
[-- Attachment #1: Type: text/plain, Size: 2182 bytes --]
Hi All,
I recently upgraded my PC to one with Intel i9-14900HX, and installed
Ubuntu22.04. Since then, remmina (as RDP client) has been periodically
crashing. I've tracked it down to a debug statement, which uses the
result of strlen():
REMMINA_PLUGIN_DEBUG("gp=%p returning %zu bytes of text in clipboard to
requesting application", gp, strlen(clipboard->srv_data));
REMMINA_PLUGIN_DEBUG is defined as:
remmina_plugin_service->_remmina_debug(__func__, fmt, ##__VA_ARGS__)
The core file shows SIGSEG at __strlen_avx2 () at
../sysdeps/x86_64/multiarch/strlen-avx2.S:74, called from
remmina_rdp_cliprdr_request_data(), so the direct call of strlen (i.e.
not called from _remmina_debug).
Clipboard has a reasonable value as does srv_data, which is a generic
pointer. Cast to char*, gdb shows the first value as '\0', so strlen()
should be 0.
Libc6 is glibc-2.35 (with Canonical's patches), but
sysdeps/x86_64/multiarch/strlen-avx2.S (as strlen) is unchanged up to 2.39.
Disassembling _strlen_avx2 shows this:
Dump of assembler code for function __strlen_avx2:
0x0000758b5c19d7e0 <+0>: endbr64
0x0000758b5c19d7e4 <+4>: mov %edi,%eax
0x0000758b5c19d7e6 <+6>: mov %rdi,%rdx
0x0000758b5c19d7e9 <+9>: vpxor %xmm0,%xmm0,%xmm0
0x0000758b5c19d7ed <+13>: and $0xfff,%eax
0x0000758b5c19d7f2 <+18>: cmp $0xfe0,%eax
0x0000758b5c19d7f7 <+23>: ja 0x758b5c19d930 <__strlen_avx2+336>
=> 0x0000758b5c19d7fd <+29>: vpcmpeqb (%rdi),%ymm0,%ymm1
0x0000758b5c19d801 <+33>: vpmovmskb %ymm1,%eax
0x0000758b5c19d805 <+37>: test %eax,%eax
0x0000758b5c19d807 <+39>: je 0x758b5c19d860 <__strlen_avx2+128>
0x0000758b5c19d809 <+41>: tzcnt %eax,%eax
0x0000758b5c19d80d <+45>: vzeroupper
0x0000758b5c19d810 <+48>: ret
I'm focusing on the instruction causing SIGSEG (marked with "=>"):
Do I understand it properly, as comparing memory addressed by RDI with
YMM0, saving the result in YMM1?
YMM0 is 0. I see where the lower 128-bits were zeroed (by zeroing
XMM0), but not the upper 128-bits. What clears them?
RDI is 0. Is this expected? Am I right that this is why I'm getting
SIGSEG?
Regards,
David
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: strlen-avx2.S
2024-06-18 5:33 strlen-avx2.S David Newall
@ 2024-06-18 18:38 ` Adhemerval Zanella Netto
2024-06-18 20:23 ` strlen-avx2.S H.J. Lu
0 siblings, 1 reply; 3+ messages in thread
From: Adhemerval Zanella Netto @ 2024-06-18 18:38 UTC (permalink / raw)
To: David Newall, libc-help, Noah Goldstein, H.J. Lu
On 18/06/24 02:33, David Newall wrote:
> Hi All,
>
> I recently upgraded my PC to one with Intel i9-14900HX, and installed Ubuntu22.04. Since then, remmina (as RDP client) has been periodically crashing. I've tracked it down to a debug statement, which uses the result of strlen():
>
> REMMINA_PLUGIN_DEBUG("gp=%p returning %zu bytes of text in clipboard to requesting application", gp, strlen(clipboard->srv_data));
>
> REMMINA_PLUGIN_DEBUG is defined as:
>
> remmina_plugin_service->_remmina_debug(__func__, fmt, ##__VA_ARGS__)
>
> The core file shows SIGSEG at __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74, called from remmina_rdp_cliprdr_request_data(), so the direct call of strlen (i.e. not called from _remmina_debug).
>
> Clipboard has a reasonable value as does srv_data, which is a generic pointer. Cast to char*, gdb shows the first value as '\0', so strlen() should be 0.
>
> Libc6 is glibc-2.35 (with Canonical's patches), but sysdeps/x86_64/multiarch/strlen-avx2.S (as strlen) is unchanged up to 2.39.
>
> Disassembling _strlen_avx2 shows this:
>
> Dump of assembler code for function __strlen_avx2:
> 0x0000758b5c19d7e0 <+0>: endbr64
> 0x0000758b5c19d7e4 <+4>: mov %edi,%eax
> 0x0000758b5c19d7e6 <+6>: mov %rdi,%rdx
> 0x0000758b5c19d7e9 <+9>: vpxor %xmm0,%xmm0,%xmm0
> 0x0000758b5c19d7ed <+13>: and $0xfff,%eax
> 0x0000758b5c19d7f2 <+18>: cmp $0xfe0,%eax
> 0x0000758b5c19d7f7 <+23>: ja 0x758b5c19d930 <__strlen_avx2+336>
> => 0x0000758b5c19d7fd <+29>: vpcmpeqb (%rdi),%ymm0,%ymm1
> 0x0000758b5c19d801 <+33>: vpmovmskb %ymm1,%eax
> 0x0000758b5c19d805 <+37>: test %eax,%eax
> 0x0000758b5c19d807 <+39>: je 0x758b5c19d860 <__strlen_avx2+128>
> 0x0000758b5c19d809 <+41>: tzcnt %eax,%eax
> 0x0000758b5c19d80d <+45>: vzeroupper
> 0x0000758b5c19d810 <+48>: ret
>
> I'm focusing on the instruction causing SIGSEG (marked with "=>"):
>
> Do I understand it properly, as comparing memory addressed by RDI with YMM0, saving the result in YMM1?
>
> YMM0 is 0. I see where the lower 128-bits were zeroed (by zeroing XMM0), but not the upper 128-bits. What clears them?
>
> RDI is 0. Is this expected? Am I right that this is why I'm getting SIGSEG?
Hi David,
Could you check which is the function argument contents, including the memory
dump of the input pointer? It helps narrow down if it is a possible issue with
the routine or with the caller.
PS: I cced the x86 maintainers.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: strlen-avx2.S
2024-06-18 18:38 ` strlen-avx2.S Adhemerval Zanella Netto
@ 2024-06-18 20:23 ` H.J. Lu
0 siblings, 0 replies; 3+ messages in thread
From: H.J. Lu @ 2024-06-18 20:23 UTC (permalink / raw)
To: Adhemerval Zanella Netto; +Cc: David Newall, Libc-help, Noah Goldstein
[-- Attachment #1: Type: text/plain, Size: 2874 bytes --]
vpxor xmm will clear all upper bits in the register.
On Wed, Jun 19, 2024, 2:39 AM Adhemerval Zanella Netto <
adhemerval.zanella@linaro.org> wrote:
>
>
> On 18/06/24 02:33, David Newall wrote:
> > Hi All,
> >
> > I recently upgraded my PC to one with Intel i9-14900HX, and installed
> Ubuntu22.04. Since then, remmina (as RDP client) has been periodically
> crashing. I've tracked it down to a debug statement, which uses the result
> of strlen():
> >
> > REMMINA_PLUGIN_DEBUG("gp=%p returning %zu bytes of text in clipboard to
> requesting application", gp, strlen(clipboard->srv_data));
> >
> > REMMINA_PLUGIN_DEBUG is defined as:
> >
> > remmina_plugin_service->_remmina_debug(__func__, fmt, ##__VA_ARGS__)
> >
> > The core file shows SIGSEG at __strlen_avx2 () at
> ../sysdeps/x86_64/multiarch/strlen-avx2.S:74, called from
> remmina_rdp_cliprdr_request_data(), so the direct call of strlen (i.e. not
> called from _remmina_debug).
> >
> > Clipboard has a reasonable value as does srv_data, which is a generic
> pointer. Cast to char*, gdb shows the first value as '\0', so strlen()
> should be 0.
> >
> > Libc6 is glibc-2.35 (with Canonical's patches), but
> sysdeps/x86_64/multiarch/strlen-avx2.S (as strlen) is unchanged up to 2.39.
> >
> > Disassembling _strlen_avx2 shows this:
> >
> > Dump of assembler code for function __strlen_avx2:
> > 0x0000758b5c19d7e0 <+0>: endbr64
> > 0x0000758b5c19d7e4 <+4>: mov %edi,%eax
> > 0x0000758b5c19d7e6 <+6>: mov %rdi,%rdx
> > 0x0000758b5c19d7e9 <+9>: vpxor %xmm0,%xmm0,%xmm0
> > 0x0000758b5c19d7ed <+13>: and $0xfff,%eax
> > 0x0000758b5c19d7f2 <+18>: cmp $0xfe0,%eax
> > 0x0000758b5c19d7f7 <+23>: ja 0x758b5c19d930 <__strlen_avx2+336>
> > => 0x0000758b5c19d7fd <+29>: vpcmpeqb (%rdi),%ymm0,%ymm1
> > 0x0000758b5c19d801 <+33>: vpmovmskb %ymm1,%eax
> > 0x0000758b5c19d805 <+37>: test %eax,%eax
> > 0x0000758b5c19d807 <+39>: je 0x758b5c19d860 <__strlen_avx2+128>
> > 0x0000758b5c19d809 <+41>: tzcnt %eax,%eax
> > 0x0000758b5c19d80d <+45>: vzeroupper
> > 0x0000758b5c19d810 <+48>: ret
> >
> > I'm focusing on the instruction causing SIGSEG (marked with "=>"):
> >
> > Do I understand it properly, as comparing memory addressed by RDI with
> YMM0, saving the result in YMM1?
> >
> > YMM0 is 0. I see where the lower 128-bits were zeroed (by zeroing
> XMM0), but not the upper 128-bits. What clears them?
> >
> > RDI is 0. Is this expected? Am I right that this is why I'm getting
> SIGSEG?
>
> Hi David,
>
> Could you check which is the function argument contents, including the
> memory
> dump of the input pointer? It helps narrow down if it is a possible issue
> with
> the routine or with the caller.
>
> PS: I cced the x86 maintainers.
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-06-18 20:23 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-06-18 5:33 strlen-avx2.S David Newall
2024-06-18 18:38 ` strlen-avx2.S Adhemerval Zanella Netto
2024-06-18 20:23 ` strlen-avx2.S H.J. Lu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).