strlen-avx2.S

[David Newall]

Bump!

On 18/6/24 15:33, David Newall wrote:
>
> 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