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