strlen-avx2.S

strlen-avx2.S

[David Newall]

[-- 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

Re: strlen-avx2.S

[Adhemerval Zanella Netto]

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.

Re: strlen-avx2.S

[H.J. Lu]

[-- 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.
>