GNU bug report logs - #79082
30.1; [reproducibility] sysinfo call during profile dump

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Dr. Werner Fink" <werner <at> suse.de>
Cc: 79082 <at> debbugs.gnu.org, ngraves <at> ngraves.fr, liliana.prikler <at> gmail.com
Subject: bug#79082: [emacs-bug] bug#79082: 30.1; [reproducibility] sysinfo call during profile dump
Date: Wed, 30 Jul 2025 15:45:36 +0300

> Date: Wed, 30 Jul 2025 14:23:06 +0200
> From: "Dr. Werner Fink" <werner <at> suse.de>
> Cc: ngraves <at> ngraves.fr, 79082 <at> debbugs.gnu.org, liliana.prikler <at> gmail.com
> 
> On 2025/07/30 14:14:34 +0300, Eli Zaretskii wrote:
> > > Date: Tue, 29 Jul 2025 13:46:59 +0200
> > > From: "Dr. Werner Fink" <werner <at> suse.de>
> > > Cc: ngraves <at> ngraves.fr, 79082 <at> debbugs.gnu.org, liliana.prikler <at> gmail.com
> > > 
> > > On 2025/07/29 14:26:43 +0300, Eli Zaretskii wrote:
> > > > 
> > > > I'm not sure we can rely on that.  Some future change might call it
> > > > more than once, in which case it will return the same value and could
> > > > break something.
> > > > 
> > > > So I would prefer making such changes where the time value is used in
> > > > a way that it makes the build not reproducible, instead of changing a
> > > > low-level function that can be used in other context.
> > > 
> > > Is there any way to remember which value will be stored in the final
> > > (p)dump image?  Like set a mark/tag in the Lisp Cons or Lisp Float to
> > > not to dump such values into the resulting (p)dump images?
> > 
> > I thought you already knew that.  If not, how did you figure out that
> > timespec_to_lisp is the place where to make the change?
> 
> I've used a C helper function with
> 
>  static int sigsegv;
>  //static const unsigned char bytarr[] = {0x68, 0x65, 0x6d, 0x0a, 0x62, 0x79, 0x20, 0x55, 0x54, 0x46, 0x2d, 0x38, 0x2e, 0x00};
>  static const unsigned char bytarr[] = {0x61, 0x02, 0x28, 0x6b, 0xee};
>  static const size_t bytlen = sizeof(bytarr)/sizeof(bytarr[0]);
>  static size_t memmatch(const void* mem, size_t mem_len, const void* pattern,
>      size_t pattern_length, size_t* pattern_index)
>  {
>      eassert(*pattern_index < pattern_length);
>      size_t idx = 0; 
>      register size_t index = *pattern_index;
>      for (; idx < mem_len;) {
>          if (((const unsigned char*)mem)[idx++] == ((const unsigned char*)pattern)[index]) {
>              ++index;
>              if (pattern_length == index) {
>                  break; // ++idx;
>              }
>          } else if (index) {
>              index = 0; // reset
>          }
>      }
>      *pattern_index = index;
>      return idx;
>  }
> 
> in dump_write() to trigger SIGSEGV or run direct in gdb with break/watch points
> and with the help of emacs-30.1/src/.gdbinit I've determined the Lisp Float and
> the Lisp Cons which changes on every run of temacs at pdump.  The first as well
> as the second bytarr is simply taken form the diffs of two od dump outputs. With
> the first something like 'by UTF-8.' and the second a very large usigned integer
> which had me reminded in gdb on seconds past epoch. The rest was a diligent but
> routine piece of work.

Thanks.  I'm not sure I understood your technique, but it's imperative
to know what Lisp values depend on build time, and then we could
discuss how best to avoid dumping them.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.