san_ignore_object not found at link time

san_ignore_object not found at link time

[T.V Raman]

Building emacs from head breaks like so:

/usr/bin/ld: emacs-module.o: in function `Fmodule_load':
/home/raman/sourceforge/emacs/src/emacs-module.c:1107: undefined reference to `__lsan_ignore_object'
collect2: error: ld returned 1 exit status
make: *** [Makefile:650: temacs] Error 1

-- 

-- 

Re: san_ignore_object not found at link time

[Eli Zaretskii]

> From: "T.V Raman" <raman@google.com>
> Date: Sat,  1 Aug 2020 07:10:14 -0700 (PDT)
> 
> Building emacs from head breaks like so:
> 
> /usr/bin/ld: emacs-module.o: in function `Fmodule_load':
> /home/raman/sourceforge/emacs/src/emacs-module.c:1107: undefined reference to `__lsan_ignore_object'
> collect2: error: ld returned 1 exit status
> make: *** [Makefile:650: temacs] Error 1

Please try again, I think I fixed that a few minutes ago.

Re: san_ignore_object not found at link time

[T.V Raman]

may not have landed yet, git pull says current branch master  is up to
date 
-- 

Re: san_ignore_object not found at link time

[Eli Zaretskii]

> Date: Sat, 01 Aug 2020 17:37:56 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: "T.V Raman" <raman@google.com>
> > Date: Sat,  1 Aug 2020 07:10:14 -0700 (PDT)
> > 
> > Building emacs from head breaks like so:
> > 
> > /usr/bin/ld: emacs-module.o: in function `Fmodule_load':
> > /home/raman/sourceforge/emacs/src/emacs-module.c:1107: undefined reference to `__lsan_ignore_object'
> > collect2: error: ld returned 1 exit status
> > make: *** [Makefile:650: temacs] Error 1
> 
> Please try again, I think I fixed that a few minutes ago.

Actually, I fixed a different problem, sorry.

Do you see HAVE_SANITIZER_LSAN_INTERFACE_H defined in your
src/config.h?  If so, it sounds like the configure-time test for this
functionality is incomplete.

Re: san_ignore_object not found at link time

[Philipp Stephani]

Am Sa., 1. Aug. 2020 um 16:45 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > Date: Sat, 01 Aug 2020 17:37:56 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: emacs-devel@gnu.org
> >
> > > From: "T.V Raman" <raman@google.com>
> > > Date: Sat,  1 Aug 2020 07:10:14 -0700 (PDT)
> > >
> > > Building emacs from head breaks like so:
> > >
> > > /usr/bin/ld: emacs-module.o: in function `Fmodule_load':
> > > /home/raman/sourceforge/emacs/src/emacs-module.c:1107: undefined reference to `__lsan_ignore_object'
> > > collect2: error: ld returned 1 exit status
> > > make: *** [Makefile:650: temacs] Error 1
> >
> > Please try again, I think I fixed that a few minutes ago.
>
> Actually, I fixed a different problem, sorry.
>
> Do you see HAVE_SANITIZER_LSAN_INTERFACE_H defined in your
> src/config.h?  If so, it sounds like the configure-time test for this
> functionality is incomplete.

Yeah, maybe we should also check for the function itself to be present.

Re: san_ignore_object not found at link time

[Alan Third]

On Sat, Aug 01, 2020 at 05:45:19PM +0300, Eli Zaretskii wrote:
> Do you see HAVE_SANITIZER_LSAN_INTERFACE_H defined in your
> src/config.h?  If so, it sounds like the configure-time test for this
> functionality is incomplete.

I'm getting a similar error:

  CCLD     temacs
Undefined symbols for architecture x86_64:
  "___lsan_ignore_object", referenced from:
      _enlarge_buffer_text in buffer.o
      _Fmake_variable_buffer_local in data.o
      _Fmake_local_variable in data.o
      _Fmodule_load in emacs-module.o
      _initialize_environment in emacs-module.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [temacs] Error 1
make: *** [src] Error 2

# grep SANITIZER src/config.h
#define HAVE_SANITIZER_LSAN_INTERFACE_H 1
-- 
Alan Third

Re: san_ignore_object not found at link time

[T.V Raman]

Eli Zaretskii <eliz@gnu.org> writes:


yes, it's defined in config.h

>> Date: Sat, 01 Aug 2020 17:37:56 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>> 
>> > From: "T.V Raman" <raman@google.com>
>> > Date: Sat,  1 Aug 2020 07:10:14 -0700 (PDT)
>> > 
>> > Building emacs from head breaks like so:
>> > 
>> > /usr/bin/ld: emacs-module.o: in function `Fmodule_load':
>> > /home/raman/sourceforge/emacs/src/emacs-module.c:1107: undefined reference to `__lsan_ignore_object'
>> > collect2: error: ld returned 1 exit status
>> > make: *** [Makefile:650: temacs] Error 1
>> 
>> Please try again, I think I fixed that a few minutes ago.
>
> Actually, I fixed a different problem, sorry.
>
> Do you see HAVE_SANITIZER_LSAN_INTERFACE_H defined in your
> src/config.h?  If so, it sounds like the configure-time test for this
> functionality is incomplete.

-- 

Re: san_ignore_object not found at link time

[Philipp Stephani]

Am Sa., 1. Aug. 2020 um 17:38 Uhr schrieb Alan Third <alan@idiocy.org>:
>
> On Sat, Aug 01, 2020 at 05:45:19PM +0300, Eli Zaretskii wrote:
> > Do you see HAVE_SANITIZER_LSAN_INTERFACE_H defined in your
> > src/config.h?  If so, it sounds like the configure-time test for this
> > functionality is incomplete.
>
> I'm getting a similar error:
>
>   CCLD     temacs
> Undefined symbols for architecture x86_64:
>   "___lsan_ignore_object", referenced from:
>       _enlarge_buffer_text in buffer.o
>       _Fmake_variable_buffer_local in data.o
>       _Fmake_local_variable in data.o
>       _Fmodule_load in emacs-module.o
>       _initialize_environment in emacs-module.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
> make[1]: *** [temacs] Error 1
> make: *** [src] Error 2
>
> # grep SANITIZER src/config.h
> #define HAVE_SANITIZER_LSAN_INTERFACE_H 1

I've pushed commit 06310cf912 which should hopefully fix this, could
you please try again?

Re: san_ignore_object not found at link time

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sat, 1 Aug 2020 19:32:40 +0200
> 
> I've pushed commit 06310cf912 which should hopefully fix this, could
> you please try again?

I now get a compilation warning:

  alloc.c: In function 'mark_maybe_object':
  alloc.c:4641:14: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   4641 |   void *po = (char *) ((intptr_t) (char *) XLP (obj)
	|              ^

This is a 32-bit build --with-wide-int, in case it matters, where
EMACS_INT is a 64-bit data type.

Re: san_ignore_object not found at link time

[Eli Zaretskii]

> Date: Sat, 01 Aug 2020 20:51:42 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: alan@idiocy.org, emacs-devel@gnu.org, p.stephani2@gmail.com,
>  raman@google.com
> 
>    4641 |   void *po = (char *) ((intptr_t) (char *) XLP (obj)
> 	  |              ^
> 
> This is a 32-bit build --with-wide-int, in case it matters, where
> EMACS_INT is a 64-bit data type.

Btw, I'm probably missing something, because I don't understand how
XLP in its current definition can work in a --with-wide-int build,
where the size of a Lisp_Object is wider than both intptr_t and a
'void *'.

Re: san_ignore_object not found at link time

[T.V Raman]

Philipp Stephani <p.stephani2@gmail.com> writes:

builds correctly > Am Sa., 1. Aug. 2020 um 17:38 Uhr schrieb Alan Third <alan@idiocy.org>:
>>
>> On Sat, Aug 01, 2020 at 05:45:19PM +0300, Eli Zaretskii wrote:
>> > Do you see HAVE_SANITIZER_LSAN_INTERFACE_H defined in your
>> > src/config.h?  If so, it sounds like the configure-time test for this
>> > functionality is incomplete.
>>
>> I'm getting a similar error:
>>
>>   CCLD     temacs
>> Undefined symbols for architecture x86_64:
>>   "___lsan_ignore_object", referenced from:
>>       _enlarge_buffer_text in buffer.o
>>       _Fmake_variable_buffer_local in data.o
>>       _Fmake_local_variable in data.o
>>       _Fmodule_load in emacs-module.o
>>       _initialize_environment in emacs-module.o
>> ld: symbol(s) not found for architecture x86_64
>> clang: error: linker command failed with exit code 1 (use -v to see invocation)
>> make[1]: *** [temacs] Error 1
>> make: *** [src] Error 2
>>
>> # grep SANITIZER src/config.h
>> #define HAVE_SANITIZER_LSAN_INTERFACE_H 1
>
> I've pushed commit 06310cf912 which should hopefully fix this, could
> you please try again?

-- 

Re: san_ignore_object not found at link time

[Alan Third]

On Sat, Aug 01, 2020 at 07:32:40PM +0200, Philipp Stephani wrote:
> Am Sa., 1. Aug. 2020 um 17:38 Uhr schrieb Alan Third <alan@idiocy.org>:
> >
> > On Sat, Aug 01, 2020 at 05:45:19PM +0300, Eli Zaretskii wrote:
> > > Do you see HAVE_SANITIZER_LSAN_INTERFACE_H defined in your
> > > src/config.h?  If so, it sounds like the configure-time test for this
> > > functionality is incomplete.
> >
> > I'm getting a similar error:
> >
> >   CCLD     temacs
> > Undefined symbols for architecture x86_64:
> >   "___lsan_ignore_object", referenced from:
> >       _enlarge_buffer_text in buffer.o
> >       _Fmake_variable_buffer_local in data.o
> >       _Fmake_local_variable in data.o
> >       _Fmodule_load in emacs-module.o
> >       _initialize_environment in emacs-module.o
> > ld: symbol(s) not found for architecture x86_64
> > clang: error: linker command failed with exit code 1 (use -v to see invocation)
> > make[1]: *** [temacs] Error 1
> > make: *** [src] Error 2
> >
> > # grep SANITIZER src/config.h
> > #define HAVE_SANITIZER_LSAN_INTERFACE_H 1
> 
> I've pushed commit 06310cf912 which should hopefully fix this, could
> you please try again?

Builds now. Thanks.
-- 
Alan Third

Re: san_ignore_object not found at link time

[Philipp Stephani]

Am Sa., 1. Aug. 2020 um 19:51 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Sat, 1 Aug 2020 19:32:40 +0200
> >
> > I've pushed commit 06310cf912 which should hopefully fix this, could
> > you please try again?
>
> I now get a compilation warning:
>
>   alloc.c: In function 'mark_maybe_object':
>   alloc.c:4641:14: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
>    4641 |   void *po = (char *) ((intptr_t) (char *) XLP (obj)
>         |              ^
>
> This is a 32-bit build --with-wide-int, in case it matters, where
> EMACS_INT is a 64-bit data type.

This is due to the unrelated commit a2323c7ccb. (I just happened to
push both commits at the same time.)
It looks like LISP_WORD_TAG in a wide int build is a 64-bit number, so
that the entire expression gets widened to a 64-bit number. However,
since it's cast back to a pointer, the value has to fit in 32 bits.

Re: san_ignore_object not found at link time

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sat, 1 Aug 2020 20:29:29 +0200
> Cc: Alan Third <alan@idiocy.org>, raman <raman@google.com>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> >   alloc.c: In function 'mark_maybe_object':
> >   alloc.c:4641:14: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> >    4641 |   void *po = (char *) ((intptr_t) (char *) XLP (obj)
> >         |              ^
> >
> > This is a 32-bit build --with-wide-int, in case it matters, where
> > EMACS_INT is a 64-bit data type.
> 
> This is due to the unrelated commit a2323c7ccb. (I just happened to
> push both commits at the same time.)
> It looks like LISP_WORD_TAG in a wide int build is a 64-bit number, so
> that the entire expression gets widened to a 64-bit number. However,
> since it's cast back to a pointer, the value has to fit in 32 bits.

The pointer is there, you just cannot safely extract it by casting to
a narrower data type.  You need to explicitly mask the MSBs by
shifting or some other bit fiddling.

Re: san_ignore_object not found at link time

[Philipp Stephani]

Am Sa., 1. Aug. 2020 um 20:03 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > Date: Sat, 01 Aug 2020 20:51:42 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: alan@idiocy.org, emacs-devel@gnu.org, p.stephani2@gmail.com,
> >  raman@google.com
> >
> >    4641 |   void *po = (char *) ((intptr_t) (char *) XLP (obj)
> >         |              ^
> >
> > This is a 32-bit build --with-wide-int, in case it matters, where
> > EMACS_INT is a 64-bit data type.
>
> Btw, I'm probably missing something, because I don't understand how
> XLP in its current definition can work in a --with-wide-int build,
> where the size of a Lisp_Object is wider than both intptr_t and a
> 'void *'.

This is somewhat subtle, but I think in this case it works because the
function bails out for the int types, and all other types are tagged
pointers.

Re: san_ignore_object not found at link time

[Philipp Stephani]

Am Sa., 1. Aug. 2020 um 20:32 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Sat, 1 Aug 2020 20:29:29 +0200
> > Cc: Alan Third <alan@idiocy.org>, raman <raman@google.com>,
> >       Emacs developers <emacs-devel@gnu.org>
> >
> > >   alloc.c: In function 'mark_maybe_object':
> > >   alloc.c:4641:14: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > >    4641 |   void *po = (char *) ((intptr_t) (char *) XLP (obj)
> > >         |              ^
> > >
> > > This is a 32-bit build --with-wide-int, in case it matters, where
> > > EMACS_INT is a 64-bit data type.
> >
> > This is due to the unrelated commit a2323c7ccb. (I just happened to
> > push both commits at the same time.)
> > It looks like LISP_WORD_TAG in a wide int build is a 64-bit number, so
> > that the entire expression gets widened to a 64-bit number. However,
> > since it's cast back to a pointer, the value has to fit in 32 bits.
>
> The pointer is there, you just cannot safely extract it by casting to
> a narrower data type.  You need to explicitly mask the MSBs by
> shifting or some other bit fiddling.

IIUC casting between unsigned integer types is guaranteed to have the
same effect.

Re: san_ignore_object not found at link time

[Andreas Schwab]

On Aug 01 2020, Eli Zaretskii wrote:

>> Date: Sat, 01 Aug 2020 20:51:42 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: alan@idiocy.org, emacs-devel@gnu.org, p.stephani2@gmail.com,
>>  raman@google.com
>> 
>>    4641 |   void *po = (char *) ((intptr_t) (char *) XLP (obj)
>> 	  |              ^
>> 
>> This is a 32-bit build --with-wide-int, in case it matters, where
>> EMACS_INT is a 64-bit data type.
>
> Btw, I'm probably missing something, because I don't understand how
> XLP in its current definition can work in a --with-wide-int build,
> where the size of a Lisp_Object is wider than both intptr_t and a
> 'void *'.

This has nothing to do with XLP.  If you add a wide integer to a pointer
you still have a pointer, whereas if you add a wide integer to a pointer
converted to intptr_t, the result is of the widened type.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: san_ignore_object not found at link time

[Philipp Stephani]

Am Sa., 1. Aug. 2020 um 20:35 Uhr schrieb Philipp Stephani
<p.stephani2@gmail.com>:
>
> Am Sa., 1. Aug. 2020 um 20:32 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
> >
> > > From: Philipp Stephani <p.stephani2@gmail.com>
> > > Date: Sat, 1 Aug 2020 20:29:29 +0200
> > > Cc: Alan Third <alan@idiocy.org>, raman <raman@google.com>,
> > >       Emacs developers <emacs-devel@gnu.org>
> > >
> > > >   alloc.c: In function 'mark_maybe_object':
> > > >   alloc.c:4641:14: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > >    4641 |   void *po = (char *) ((intptr_t) (char *) XLP (obj)
> > > >         |              ^
> > > >
> > > > This is a 32-bit build --with-wide-int, in case it matters, where
> > > > EMACS_INT is a 64-bit data type.
> > >
> > > This is due to the unrelated commit a2323c7ccb. (I just happened to
> > > push both commits at the same time.)
> > > It looks like LISP_WORD_TAG in a wide int build is a 64-bit number, so
> > > that the entire expression gets widened to a 64-bit number. However,
> > > since it's cast back to a pointer, the value has to fit in 32 bits.
> >
> > The pointer is there, you just cannot safely extract it by casting to
> > a narrower data type.  You need to explicitly mask the MSBs by
> > shifting or some other bit fiddling.
>
> IIUC casting between unsigned integer types is guaranteed to have the
> same effect.

I've now used INT_SUBTRACT_WRAPV, which should guarantee that the
offset is defined and fits within an intptr_t.

Re: san_ignore_object not found at link time

[Philipp Stephani]

Am Sa., 1. Aug. 2020 um 21:17 Uhr schrieb Philipp Stephani
<p.stephani2@gmail.com>:
>
> Am Sa., 1. Aug. 2020 um 20:35 Uhr schrieb Philipp Stephani
> <p.stephani2@gmail.com>:
> >
> > Am Sa., 1. Aug. 2020 um 20:32 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
> > >
> > > > From: Philipp Stephani <p.stephani2@gmail.com>
> > > > Date: Sat, 1 Aug 2020 20:29:29 +0200
> > > > Cc: Alan Third <alan@idiocy.org>, raman <raman@google.com>,
> > > >       Emacs developers <emacs-devel@gnu.org>
> > > >
> > > > >   alloc.c: In function 'mark_maybe_object':
> > > > >   alloc.c:4641:14: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > > > >    4641 |   void *po = (char *) ((intptr_t) (char *) XLP (obj)
> > > > >         |              ^
> > > > >
> > > > > This is a 32-bit build --with-wide-int, in case it matters, where
> > > > > EMACS_INT is a 64-bit data type.
> > > >
> > > > This is due to the unrelated commit a2323c7ccb. (I just happened to
> > > > push both commits at the same time.)
> > > > It looks like LISP_WORD_TAG in a wide int build is a 64-bit number, so
> > > > that the entire expression gets widened to a 64-bit number. However,
> > > > since it's cast back to a pointer, the value has to fit in 32 bits.
> > >
> > > The pointer is there, you just cannot safely extract it by casting to
> > > a narrower data type.  You need to explicitly mask the MSBs by
> > > shifting or some other bit fiddling.
> >
> > IIUC casting between unsigned integer types is guaranteed to have the
> > same effect.
>
> I've now used INT_SUBTRACT_WRAPV, which should guarantee that the
> offset is defined and fits within an intptr_t.

However, I guess when using wide ints *and* MSB tags the subtraction
might overflow, so maybe the assertion should be conditioned on that
case.

Re: san_ignore_object not found at link time

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sat, 1 Aug 2020 21:17:05 +0200
> Cc: Alan Third <alan@idiocy.org>, raman <raman@google.com>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> I've now used INT_SUBTRACT_WRAPV, which should guarantee that the
> offset is defined and fits within an intptr_t.

Thanks, the warning is gone now.  Though I still don't like the code
there, it feels wrong even if it isn't.

Re: san_ignore_object not found at link time

[Eli Zaretskii]

> Date: Sat, 01 Aug 2020 22:21:24 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: alan@idiocy.org, emacs-devel@gnu.org, raman@google.com
> 
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Sat, 1 Aug 2020 21:17:05 +0200
> > Cc: Alan Third <alan@idiocy.org>, raman <raman@google.com>, 
> > 	Emacs developers <emacs-devel@gnu.org>
> > 
> > I've now used INT_SUBTRACT_WRAPV, which should guarantee that the
> > offset is defined and fits within an intptr_t.
> 
> Thanks, the warning is gone now.  Though I still don't like the code
> there, it feels wrong even if it isn't.

I spoke too soon: it compiles, but that hits assertion violation while
loading:

    CCLD     temacs.exe
  /bin/mkdir -p ../etc
  make -C ../lisp update-subdirs
  make[2]: Entering directory `/d/gnu/git/emacs/trunk/lisp'
  make[2]: Leaving directory `/d/gnu/git/emacs/trunk/lisp'
  cp -f temacs.exe bootstrap-emacs.exe
  rm -f bootstrap-emacs.pdmp
  ./temacs --batch  -l loadup --temacs=pbootstrap
  Loading loadup.el (source)...
  dump mode: pbootstrap
  Using load-path (d:/gnu/git/emacs/trunk/lisp d:/gnu/git/emacs/trunk/lisp/emacs-lisp d:/gnu/git/emacs/trunk/lisp/progmodes d:/gnu/git/emacs/trunk/lisp/language d:/gnu/git/emacs/trunk/lisp/international d:/gnu/git/emacs/trunk/lisp/textmodes d:/gnu/git/emacs/trunk/lisp/vc)
  Loading emacs-lisp/byte-run...
  Loading emacs-lisp/backquote...
  Loading subr...
  Loading version...

  alloc.c:4646: Emacs fatal error: assertion failed: !overflow

Here's the backtrace, FTR:

  #1  0x0133f574 in emacs_abort () at w32fns.c:10832
  #2  0x01159bd7 in terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:409
  #3  0x01218a3e in die (msg=0x173efad <STRING_BYTES_MAX+1977> "!overflow",
      file=0x173e5aa <DEFAULT_REHASH_SIZE+286> "alloc.c", line=4646)
      at alloc.c:7362
  #4  0x012124da in mark_maybe_object (obj=XIL(0xc0000000058ab680))
      at alloc.c:4646
  #5  0x012129e4 in mark_memory (start=0x82d818, end=0x82feac) at alloc.c:4864
  #6  0x01212a0c in mark_stack (bottom=0x82feac "", end=0x82d818 "H╪ג")
      at alloc.c:5047
  #7  0x0132015b in mark_one_thread (thread=0x1703000 <main_thread>)
      at thread.c:630
  #8  0x01320290 in mark_threads_callback (ignore=0x0) at thread.c:661
  #9  0x01212a36 in flush_stack_call_func1 (
      func=0x1320212 <mark_threads_callback>, arg=0x0) at alloc.c:5088
  #10 0x0131f39a in flush_stack_call_func (
      func=0x1320212 <mark_threads_callback>, arg=0x0) at lisp.h:3837
  #11 0x013202c0 in mark_threads () at thread.c:668
  #12 0x0121555c in garbage_collect () at alloc.c:6077
  #13 0x01215b05 in Fgarbage_collect () at alloc.c:6193
  #14 0x01258cdf in eval_sub (form=XIL(0xc0000000058ac280)) at eval.c:2271
  #15 0x012517f0 in Fprogn (body=XIL(0)) at eval.c:462
  #16 0x0125c82b in funcall_lambda (fun=XIL(0xc0000000058ac2d0), nargs=1,
      arg_vector=0x82e010) at eval.c:3065
  #17 0x0125b3de in Ffuncall (nargs=2, args=0x82e008) at eval.c:2809
  #18 0x01259c69 in funcall_nil (nargs=2, args=0x82e008) at eval.c:2436
  #19 0x0125a2d8 in run_hook_with_args (nargs=2, args=0x82e008,
      funcall=0x1259c51 <funcall_nil>) at eval.c:2613
  #20 0x01259ce1 in Frun_hook_with_args (nargs=2, args=0x82e008) at eval.c:2478
  #21 0x0125b678 in funcall_subr (subr=0x170bb60 <Srun_hook_with_args>,
      numargs=2, args=0x82e008) at eval.c:2848
  #22 0x0125b1e6 in Ffuncall (nargs=3, args=0x82e000) at eval.c:2795
  #23 0x012c50a5 in exec_byte_code (bytestr=XIL(0x8000000005a35ad8),
      vector=XIL(0xa000000005888560), maxdepth=make_fixnum(12),
      args_template=make_fixnum(257), nargs=1, args=0x82e6a0) at bytecode.c:635
  #24 0x0125bd15 in fetch_and_exec_byte_code (fun=XIL(0xa000000005888670),
      syms_left=make_fixnum(257), nargs=1, args=0x82e698) at eval.c:2917
  #25 0x0125c292 in funcall_lambda (fun=XIL(0xa000000005888670), nargs=1,
      arg_vector=0x82e698) at eval.c:2998
  #26 0x0125b240 in Ffuncall (nargs=2, args=0x82e690) at eval.c:2797
  #27 0x0125a512 in call1 (fn=XIL(0x5040), arg1=XIL(0x8000000005a38c08))
      at eval.c:2655
  #28 0x012a50bc in Fload (file=XIL(0x8000000005a38ba8), noerror=XIL(0),
      nomessage=XIL(0), nosuffix=XIL(0), must_suffix=XIL(0)) at lread.c:1480
  #29 0x01258f1c in eval_sub (form=XIL(0xc0000000058ac310)) at eval.c:2288
  #30 0x012a7c23 in readevalloop (readcharfun=XIL(0x6d20), infile0=0x82f5fc,
      sourcename=XIL(0x800000000599cc10), printflag=false, unibyte=XIL(0),
      readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2096
  #31 0x012a4f1c in Fload (file=XIL(0x800000000599cb50), noerror=XIL(0),
      nomessage=XIL(0), nosuffix=XIL(0), must_suffix=XIL(0)) at lread.c:1465
  #32 0x01258f1c in eval_sub (form=XIL(0xc000000005895120)) at eval.c:2288
  #33 0x012581b0 in Feval (form=XIL(0xc000000005895120), lexical=XIL(0))
      at eval.c:2103
  #34 0x0116160f in top_level_2 () at keyboard.c:1100
  #35 0x012557e0 in internal_condition_case (bfun=0x11615dc <top_level_2>,
      handlers=XIL(0x90), hfun=0x1160d8d <cmd_error>) at eval.c:1356
  #36 0x01161689 in top_level_1 (ignore=XIL(0)) at keyboard.c:1108
  #37 0x012549ed in internal_catch (tag=XIL(0xe070),
      func=0x1161615 <top_level_1>, arg=XIL(0)) at eval.c:1117
  #38 0x011614e1 in command_loop () at keyboard.c:1069
  #39 0x0116081d in recursive_edit_1 () at keyboard.c:714
  #40 0x01160a8b in Frecursive_edit () at keyboard.c:786
  #41 0x0115c2a0 in main (argc=5, argv=0xa44250) at emacs.c:2043

  Lisp Backtrace:
  "Automatic GC" (0x0)
  "garbage-collect" (0x82daf8)
  0x58ac2d0 Lisp type 6
  "run-hook-with-args" (0x82e008)
  "do-after-load-evaluation" (0x82e698)
  "load" (0x82edf8)
  "load" (0x82f758)

Re: san_ignore_object not found at link time

[Philipp Stephani]

Am Sa., 1. Aug. 2020 um 21:26 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > Date: Sat, 01 Aug 2020 22:21:24 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: alan@idiocy.org, emacs-devel@gnu.org, raman@google.com
> >
> > > From: Philipp Stephani <p.stephani2@gmail.com>
> > > Date: Sat, 1 Aug 2020 21:17:05 +0200
> > > Cc: Alan Third <alan@idiocy.org>, raman <raman@google.com>,
> > >     Emacs developers <emacs-devel@gnu.org>
> > >
> > > I've now used INT_SUBTRACT_WRAPV, which should guarantee that the
> > > offset is defined and fits within an intptr_t.
> >
> > Thanks, the warning is gone now.  Though I still don't like the code
> > there, it feels wrong even if it isn't.
>
> I spoke too soon: it compiles, but that hits assertion violation while
> loading:

Yeah, that's what I feared. I've now made the assertion conditional.

It might be cleaner to rewrite that function to explicitly check for
all known tag types:

void *po;
switch (type_tag)
{
  case Lisp_Symbol:
    po = XSYMBOL (obj);
    break;
  ...
}

That way, the pointer arithmetic would be centralized in XUNTAG and XSYMBOL.

Re: san_ignore_object not found at link time

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sat, 1 Aug 2020 21:40:02 +0200
> Cc: Alan Third <alan@idiocy.org>, Emacs developers <emacs-devel@gnu.org>, raman <raman@google.com>
> 
> Yeah, that's what I feared. I've now made the assertion conditional.

The assertion is gone, thanks.

> It might be cleaner to rewrite that function to explicitly check for
> all known tag types:

Something like that.  Anything, really, because when I see the likes
of

   #  define lisp_h_XLP(o) ((void *) (uintptr_t) (o))

and know that 'o' can be a 64-bit integer whereas pointers are 32-bit
wide, I get shivers.