gl_array_list.c:452:29: runtime error: applying zero offset to null pointer

gl_array_list.c:452:29: runtime error: applying zero offset to null pointer

[Paweł Krawczyk]

Hello, I'm running an application using gl_array_list under clang ASAN and getting the following complaints:

gl_array_list.c:452:29: runtime error: applying zero offset to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior gl_array_list.c:452:29 in
gl_array_list.c:453:29: runtime error: applying zero offset to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior gl_array_list.c:453:29 in

Linest 452-453 are gl_array_list.c:

  result.p = list->elements + 0;
  result.q = list->elements + list->count;

And indeed, when inspected I found out that the list passed to the iterator was empty. A simple check using
gl_list_size() prior to calling the iterator solved the problem in my program but maybe that should be also
implemented inside the iterator.


The broader context:

static gl_list_iterator_t _GL_ATTRIBUTE_PURE
gl_array_iterator (gl_list_t list)
{
  gl_list_iterator_t result;

  result.vtable = list->base.vtable;
  result.list = list;
  result.count = list->count;
  result.p = list->elements + 0;
  result.q = list->elements + list->count;
#if defined GCC_LINT || defined lint
  result.i = 0;
  result.j = 0;
#endif

  return result;
}

The command used to compile along with ASAN options:

libtool: compile:  clang -DHAVE_CONFIG_H -I. -I.. -g -O2 -fstack-protector-all -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -O0 -ggdb -fstack-protector-all -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fsanitize=address -fsanitize=undefined -fsanitize=leak -fsanitize-address-use-after-scope -fcf-protection=full -MT gl_array_list.lo -MD -MP -MF .deps/gl_array_list.Tpo -c gl_array_list.c  -fPIC -DPIC -o .libs/gl_array_list.o


-- 
Pawel Krawczyk
pawel.krawczyk@hush.com +44 7879 180015
CISSP, OWASP, MBCS, CESG SIRA

Re: gl_array_list.c:452:29: runtime error: applying zero offset to null pointer

[Paul Eggert]

On 10/21/21 12:38, Paweł Krawczyk wrote:

> gl_array_list.c:452:29: runtime error: applying zero offset to null pointer
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior gl_array_list.c:452:29 in

The Gnulib portability assumptions 
<https://www.gnu.org/software/gnulib/manual/html_node/Other-portability-assumptions.html> 
say it's OK to add 0 to a null pointer. If you have a real platform 
(i.e., not a pedantic testing framework) where this is an issue, please 
let us know. Otherwise you might look into some way to have clang not 
nag you about this non-problem.

Re: gl_array_list.c:452:29: runtime error: applying zero offset to null pointer

[Jeffrey Walton]

On Mon, Nov 1, 2021 at 4:02 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> On 10/21/21 12:38, Paweł Krawczyk wrote:
>
> > gl_array_list.c:452:29: runtime error: applying zero offset to null pointer
> > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior gl_array_list.c:452:29 in
>
> The Gnulib portability assumptions
> <https://www.gnu.org/software/gnulib/manual/html_node/Other-portability-assumptions.html>
> say it's OK to add 0 to a null pointer. If you have a real platform
> (i.e., not a pedantic testing framework) where this is an issue, please
> let us know. Otherwise you might look into some way to have clang not
> nag you about this non-problem.

I believe that's undefined behavior. NULL is not a valid object. I
think the tools are correct in producing a finding.

https://stackoverflow.com/questions/26906621

Jeff

Re: gl_array_list.c:452:29: runtime error: applying zero offset to null pointer

[Paul Eggert]

On 11/1/21 17:46, Jeffrey Walton wrote:
> I believe that's undefined behavior.

Yes, of course it is. But the Gnulib code works on all practical 
platforms, so it's OK. Gnulib is a practical project not a theoretical 
one, and it uses undefined behavior in several ways other than this one. 
As long as the code works on real systems there's no real problem.

Most likely Paweł can configure his testing environment to suppress 
these false alarms. If not, I suggest firing off a bug report to the 
Clang developers, asking for an easy way to suppress them. In practice 
these particular diagnostics are more trouble than they're worth.

Re: gl_array_list.c:452:29: runtime error: applying zero offset to null pointer

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

On 11/1/21 18:13, Paul Eggert wrote:
> 
> Most likely Paweł can configure his testing environment to suppress 
> these false alarms. If not, I suggest firing off a bug report to the 
> Clang developers, asking for an easy way to suppress them. In practice 
> these particular diagnostics are more trouble than they're worth.

While rereading the Gnulib manual I remembered this issue, found a way 
to suppress Clang's false alarms, and documented it in the attached 
Gnulib patch.

[-- Attachment #2: 0001-Document-clang-fsanitize-undefined-glitch.patch --]
[-- Type: text/x-patch, Size: 2159 bytes --]

From 532b4c9f21473559657e273ef9f8f6fc8c7c2ab1 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 26 Feb 2022 11:39:32 -0800
Subject: [PATCH] Document clang -fsanitize=undefined glitch
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* doc/gnulib-intro.texi (Unsupported Platforms):
Document incompatibility of ‘clang -fsanitize=undefined’
with Gnulib, and how to work around it by also using
‘-fno-sanitize=pointer-overflow’.
---
 ChangeLog             |  8 ++++++++
 doc/gnulib-intro.texi | 11 +++++++++++
 2 files changed, 19 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index 6daf85da3e..430f81fd39 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2022-02-26  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Document clang -fsanitize=undefined glitch
+	* doc/gnulib-intro.texi (Unsupported Platforms):
+	Document incompatibility of ‘clang -fsanitize=undefined’
+	with Gnulib, and how to work around it by also using
+	‘-fno-sanitize=pointer-overflow’.
+
 2022-02-25  Darshit Shah  <darnir@gnu.org>
 
 	modules/unicase/special-casing: Fix compilation error
diff --git a/doc/gnulib-intro.texi b/doc/gnulib-intro.texi
index a80c0995f5..0bc9701561 100644
--- a/doc/gnulib-intro.texi
+++ b/doc/gnulib-intro.texi
@@ -235,6 +235,17 @@ and Gnulib-using code would have if it were intended to be portable to
 all practical POSIX or C platforms.
 
 @itemize @bullet
+@item
+Clang's @option{-fsanitize=undefined} option causes the program to
+crash if it adds zero to a null pointer -- behavior that is undefined
+in strict C, but which yields a null pointer on all practical porting
+targets and which the Gnulib portability guidelines allow.
+
+If you use Clang with @option{-fsanitize=undefined}, you can work
+around the problem by also using @samp{-fno-sanitize=pointer-overflow},
+although this may also disable some unrelated and useful pointer checks.
+Perhaps someday the Clang developers will fix the infelicity.
+
 @item
 The IBM i's pointers are 128 bits wide and it lacks the two types
 @code{intptr_t} and @code{uintptr_t}, which are optional in the C and
-- 
2.32.0