Builder libpcap-solaris10-amd64 Build #3287

Results:

Build successful

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-libpcap-solaris10-amd64' triggered this build

Steps and Logfiles:

1. git update ( 5 secs )
   1. stdio
2. shell Set developer mode ( 0 secs )
   1. stdio
3. shell_1 './autogen.sh' ( 6 secs )
   1. stdio
4. shell_2 './configure' ( 45 secs )
   1. stdio
   2. config.log
5. shell_3 'gmake' ( 22 secs )
   1. stdio
6. shell_4 'gmake check' ( 13 mins, 40 secs )
   1. stdio
7. shell_5 'rm -rf ...' ( 0 secs )
   1. stdio
8. shell_6 'gmake install ...' ( 3 secs )
   1. stdio
9. trigger triggered trigger-tcpdump-solaris10-amd64 ( 6 mins, 14 secs )
   1. - no logs -
   2. tcpdump-solaris10-amd64 #6176

Build Properties:

Forced Build Properties:

Responsible Users:

1. Denis Ovsienko

   denisohnoyoudont@ovsienko.info

Timing:

All Changes:

:

1. Change #262844

   Category	libpcap
   Changed by	Denis Ovsienko <denisohnoyoudont@ovsienko.info>
   Changed at	Sat 28 Mar 2026 12:50:50
   Repository	https://git.tcpdump.org/libpcap
   Project	libpcap
   Branch	master
   Revision	6cbce587926aa9e4c5a7749e41813f4ff1971578

   Comments

   Keep compiler_state_t.cur_chunk less than NCHUNKS.
   When newchunk_nolongjmp() finds that the current chunk does not have
   enough free space for the requested data size, it allocates the next
   chunk if the chunk count limit has not been reached, otherwise it
   returns an error.  As Aniruddhan Murali from University of Waterloo
   points it out, in the latter case it also increments the chunk index
   beyond the end of the array, which potentially could cause an OOBR in a
   subsequent invocation of the function and snowball from there.
   
   However, the current definition of struct compiler_state_t means the
   first such subsequent invocation would read out of the array bounds, but
   still from within the structure and would always return an error.  The
   only code path where this was possible always terminated parsing on the
   error, and no longer exists since commit 6fe3ac3, so by coincidence this
   bug has been harmless for a long time, if not always.
   
   To make this code obviously safe, first check that the current chunk is
   not the last, only then increment the chunk index, not the opposite way
   around.  While at it, make the error message more useful for any future
   debugging and access the current chunk index without an intermediate
   variable.

   Changed files

   • gencode.c

2. Change #262845

   Category	libpcap
   Changed by	Denis Ovsienko <denisohnoyoudont@ovsienko.info>
   Changed at	Sun 29 Mar 2026 14:42:19
   Repository	https://git.tcpdump.org/libpcap
   Project	libpcap
   Branch	master
   Revision	726d5040e216227a82da76e6e84177eaae286a08

   Comments

   Make other chunk allocation improvements.
   Make the chunk size an unary macro rather than a variable.  Make chunk
   index unsigned.  Introduce a helper function with additional validation
   and a more useful error message to initialise the current chunk.  Use
   the latter in initchunks() to start the data allocations in chunk 0
   rather than chunk 1.
   
   In newchunk_nolongjmp(), if the requested data size is too big for both
   the current chunk and the next chunk, there is no point in having the
   side effect of initialising the next chunk, so in this case just return
   an error early.  Ibid., lose the pointer to the current chunk because
   using two ways to acess the same data creates a space for an error.
   Ibid., use the new helper function and make another error message more
   useful.

   Changed files

   • gencode.c