fsanitize: member access within null pointer

Kornel Benko kornel at lyx.org
Sun Dec 26 08:48:11 UTC 2021


Am Sat, 25 Dec 2021 18:08:55 +0100
schrieb Pavel Sanda <sanda at lyx.org>:

> On Thu, Dec 16, 2021 at 04:35:39PM +0100, Kornel Benko wrote:
> > As strings:
> > (gdb) x/10s &addr
> > 0x7fffffffd788:	"\001"
> > 0x7fffffffd78a:	"/tmp/lyx_tmpdir.kVhnZYL31128/lyxsocket"
> > 0x7fffffffd7b1:	""
> > 0x7fffffffd7b2:	""
> > 0x7fffffffd7b3:	""
> > 0x7fffffffd7b4:	""
> > 0x7fffffffd7b5:	""
> > 0x7fffffffd7b6:	""
> > 0x7fffffffd7b7:	""
> > 0x7fffffffd7b8:	"|"
> > (gdb)   
> 
> This looks fine.
> 
> Maybe it's because SUN_LEN macro.
> 
> In my system I see in /usr/include/x86_64-linux-gnu/sys/un.h
> # define SUN_LEN(ptr) ((size_t) (((struct sockaddr_un *) 0)->sun_path)        \
>                       + strlen ((ptr)->sun_path))

Same here

> I guess clang is not happy with (((struct sockaddr_un *) 0)->sun_path)
> 
> Our own code has:
> #if !defined(SUN_LEN)
> #define SUN_LEN(su) \
>         (sizeof (*(su)) - sizeof ((su)->sun_path) + strlen((su)->sun_path))
> #endif

That was a good guess! With the attached change the message does not appear anymore.

> which does not have this constrt and clang might be happier.
> I do not known what headers gets included with clang though.
> 
> Pavel

	Kornel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: socktools.cpp.patch
Type: text/x-patch
Size: 829 bytes
Desc: not available
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20211226/221428bf/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20211226/221428bf/attachment.asc>


More information about the lyx-devel mailing list