Home - Waterfall Grid T-Grid Console Builders Recent Builds Buildslaves Changesources - JSON API - About

Builder libpcap-solaris10-i386 Build #3300

Results:

Build successful

SourceStamp:

Projectlibpcap
Repositoryhttps://git.tcpdump.org/libpcap
Branchmaster
Revisione2fe69377b84cf5e963b54946cb616cfbc4a76d4
Got Revisione2fe69377b84cf5e963b54946cb616cfbc4a76d4
Changes11 changes

BuildSlave:

unstable10x

Reason:

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

Steps and Logfiles:

  1. git update ( 6 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' ( 50 secs )
    1. stdio
    2. config.log
  5. shell_3 'gmake' ( 27 secs )
    1. stdio
  6. shell_4 'gmake check' ( 14 mins, 7 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-i386 ( 6 mins, 2 secs )
    1. - no logs -
    2. tcpdump-solaris10-i386 #6110

Build Properties:

NameValueSource
branch master Build
builddir /export/home/buildbot/slave/libpcap-solaris10-i386 slave
buildername libpcap-solaris10-i386 Builder
buildnumber 3300 Build
codebase Build
got_revision e2fe69377b84cf5e963b54946cb616cfbc4a76d4 Git
project libpcap Build
repository https://git.tcpdump.org/libpcap Build
revision e2fe69377b84cf5e963b54946cb616cfbc4a76d4 Build
scheduler schedule-libpcap-solaris10-i386 Scheduler
slavename unstable10x BuildSlave
workdir /export/home/buildbot/slave/libpcap-solaris10-i386 slave (deprecated)

Forced Build Properties:

NameLabelValue

Responsible Users:

  1. Denis Ovsienko

Timing:

StartWed Sep 30 09:04:59 2026
EndWed Sep 30 09:26:43 2026
Elapsed21 mins, 44 secs

All Changes:

:

  1. Change #283766

    Category libpcap
    Changed by Denis Ovsienko <denisohnoyoudont@ovsienko.info>
    Changed at Mon 28 Sep 2026 11:45:18
    Repository https://git.tcpdump.org/libpcap
    Project libpcap
    Branch master
    Revision 7e5a764714bf1edc11f3708d3d103e6a1c0aa4c0

    Comments

    Specify the load size for all addressing modes.
All BPF_IMM, BPF_LEN and BPF_MEM addressing mode loads are 32-bit.  For
BPF_IMM and BPF_LEN some code specifies BPF_W and some does not, for
BPF_MEM no code specifies BPF_W.  This does not cause any difference in
the resulting opcodes because BPF_W is defined to zero, but it makes the
code more difficult to follow, so always specify BPF_W for these three
addressing modes.  Now all load opcodes include an explicit load size.

Arguably, for loads that are 32-bit only (e.g. BPF_LD|BPF_W|BPF_IMM) the
BPF_W could be declared an unwanted tautology, and for all other loads
(e.g. BPF_LD|BPF_W|BPF_ABS) BPF_W could be declared mandatory to make it
obvious that BPF_H and BPF_B would also be valid.  However, this
semantics would not be able to accommodate BPF_LDX|BPF_B|BPF_MSH, which
must specify BPF_B to make it clear the size does not default to BPF_W,
and which does not support any other sizes.

    Changed files

    • bpf_filter.c
    • bpf_image.c
    • gencode.c
    • optimize.c
    • testprogs/TESTrun

  2. Change #283767

    Category libpcap
    Changed by Denis Ovsienko <denisohnoyoudont@ovsienko.info>
    Changed at Mon 28 Sep 2026 11:46:18
    Repository https://git.tcpdump.org/libpcap
    Project libpcap
    Branch master
    Revision 78ad7208a21813bfa3cb6b29f9afa114d3f9b32b

    Comments

    gencode: Generalise JMP() into arity guards.
To extend the solution space of commit 949f5fc onto all BPF instruction
groups, introduce OPCODE_2ARY() and OPCODE_3ARY().  For branch
instructions replace JMP() with OPCODE_BRANCH_X() and OPCODE_BRANCH_K(),
for return instructions introduce OPCODE_RET() and for miscellaneous
instructions introduce OPCODE_MISC().

Apply the same guard to the 'k' field of an instruction: introduce
new_stmt_k() and for every instruction define a wrapper around either
new_stmt() or new_stmt_k().  This leaves less space for out-of-place
assignments of 'k' such as those removed in commit baacfde.

    Changed files

    • gencode.c

  3. Change #283768

    Category libpcap
    Changed by Denis Ovsienko <denisohnoyoudont@ovsienko.info>
    Changed at Mon 28 Sep 2026 11:46:18
    Repository https://git.tcpdump.org/libpcap
    Project libpcap
    Branch master
    Revision 16d2803c1e66f9b77241df49a3daa8baeb68399e

    Comments

    gencode: Use arity guards for ALU instructions.
This leaves less space for opcode composition errors such as those
fixed in commit 69e8ab1.

    Changed files

    • gencode.c

  4. Change #283769

    Category libpcap
    Changed by Denis Ovsienko <denisohnoyoudont@ovsienko.info>
    Changed at Mon 28 Sep 2026 11:46:18
    Repository https://git.tcpdump.org/libpcap
    Project libpcap
    Branch master
    Revision 8eec5cb04cdd9a5dc088f16a012d301c84284f08

    Comments

    gencode: Use arity guards for load instructions.

    Changed files

    • gencode.c

  5. Change #283770

    Category libpcap
    Changed by Denis Ovsienko <denisohnoyoudont@ovsienko.info>
    Changed at Mon 28 Sep 2026 11:46:18
    Repository https://git.tcpdump.org/libpcap
    Project libpcap
    Branch master
    Revision 49262b6a05a20642a6ff1b307c338e8feff06129

    Comments

    gencode: Use arity guards for store instructions.

    Changed files

    • gencode.c

  6. Change #283771

    Category libpcap
    Changed by Denis Ovsienko <denisohnoyoudont@ovsienko.info>
    Changed at Mon 28 Sep 2026 11:46:18
    Repository https://git.tcpdump.org/libpcap
    Project libpcap
    Branch master
    Revision 17c2d1e6d778d68610b9024e7db9c8650b7e98a5

    Comments

    TESTrun: Start testing scratch memory capacity.
Test many enough repetitions of "geneve", "vxlan" and "protochain" to
make the code generator run out of registers.  Test a Cartesian product
of {DLT_EN10MB, DLT_IEEE802_11}, {"link[]", "tcp[]"} and an arithmetic
expression wrapper that needs [14, 17] scratch memory registers to
represent.

The latter loosely relates with the structure of tests in commit
a8c1362, but covers fewer code paths and permutations: this time the
focus is on how many registers are allocated before, in and downstream
of gen_load_internal().  All test cases in the 14 register plane are
expected to work.  All test cases in the 17 registers plane are expected
to fail.  The tests in the 15 and 16 register planes are expected to
produce different results as each test flexes a different corner case.

    Changed files

    • testprogs/TESTrun

  7. Change #283772

    Category libpcap
    Changed by Denis Ovsienko <denisohnoyoudont@ovsienko.info>
    Changed at Mon 28 Sep 2026 11:46:18
    Repository https://git.tcpdump.org/libpcap
    Project libpcap
    Branch master
    Revision cd0e30d920eb6679b3810442ac204490e758fbc5

    Comments

    Fix a dangling register index in "proto[expr]".
When libpcap 1.0.0 in 2008 introduced (see commit 489f459) support for
variable-length headers, it also turned an imperfection that originates
in tcpdump 2.0 (1991) into an obscure bug.

gen_load_internal() incorrectly deallocates the input register before
gen_load_absoffsetarthrel() is done using it.  If the load uses a header
or payload offset that in the current DLT has a variable length, between
these two events gen_load_internal() invokes gen_abs_offset_varpart()
directly or via gen_loadx_iphdrlen().  If gen_abs_offset_varpart() has
not been invoked before, the function uses alloc_reg() to allocate a
register for the variable offset, which can allocate the prematurely
deallocated input register.

Typically the bug does not manifest: the deallocated and the allocated
registers are different because of a side effect.  Specifically, the
input register is allocated just before gen_load_internal(), so when the
current revision of gen_load_internal() just before the free_reg()
invocation makes another alloc_reg() invocation, the latter rotates the
current register index (which it will try allocating first at the next
invocation) away from the still allocated input register.

However, if that alloc_reg()/free_reg() sequence has allocated the last
available register before deallocating the input register, the input
register will be the only "available" register and will become the
result of alloc_reg() in gen_abs_offset_varpart().  The resulting filter
program first calculates the variable offset and stores it in a register
that is supposed to hold it for the entire run time of the program.
Later on the arithmetic expression that is the offset of a packet data
accessor stores its result into the same register and affects all
subsequent loads that use the variable offset, including the indirect
load of the packet data accessor.

To fix this, deallocate the register /after/ the use and add a comment
to clarify it.  Convert the test that reproduced the bug to a reject
test as the code no longer fails to fail.

    Changed files

    • CHANGES
    • gencode.c
    • testprogs/TESTrun

  8. Change #283773

    Category libpcap
    Changed by Denis Ovsienko <denisohnoyoudont@ovsienko.info>
    Changed at Mon 28 Sep 2026 11:46:18
    Repository https://git.tcpdump.org/libpcap
    Project libpcap
    Branch master
    Revision 0af43c2281403ff4b7614aca1d9baf5bbbac45b5

    Comments

    Make a dangling register index an early failure.
Introduce guard_reg() to detect obvious register-related bugs such as
the one fixed in the previous commit.  Introduce free_reg_arth() to make
some less obvious register-related bugs obvious.

    Changed files

    • gencode.c

  9. Change #283774

    Category libpcap
    Changed by Denis Ovsienko <denisohnoyoudont@ovsienko.info>
    Changed at Mon 28 Sep 2026 11:46:18
    Repository https://git.tcpdump.org/libpcap
    Project libpcap
    Branch master
    Revision b67b2098c0266dad56e1e4d52054156bc97dca6b

    Comments

    Fix a register index leak in "protochain".
When libpcap 0.5 in 2000 introduced (see commit 7fe3c11) support for
"protochain", the initial revision of gen_protochain() allocated two
scratch memory registers on every invocation, but used and deallocated
these only if the primitive was proto-qualified.  In libpcap release 0.6
(2001) the problem had reduced (see commit 142ff8d) to one register, yet
remained in principle.

To fix this, allocate the register only after it is certain the function
is going to generate statements and to deallocate the register.  Convert
a bug reproducer to a regression test -- an expression that used to run
out of registers now compiles to hundreds of instructions and uses M[0]
only.  Update one accept test that now uses M[0] instead of M[1] because
M[0] is not leaked anymore.

    Changed files

    • CHANGES
    • gencode.c
    • testprogs/TESTrun

  10. Change #283775

    Category libpcap
    Changed by Denis Ovsienko <denisohnoyoudont@ovsienko.info>
    Changed at Wed 30 Sep 2026 10:34:39
    Repository https://git.tcpdump.org/libpcap
    Project libpcap
    Branch master
    Revision bf41d9722bf2a8c3633cf1980347879764e6183a

    Comments

    Capitalise "Internet" properly in comments. [skip ci]

    Changed files

    • nametoaddr.c

  11. Change #283776

    Category libpcap
    Changed by Denis Ovsienko <denisohnoyoudont@ovsienko.info>
    Changed at Wed 30 Sep 2026 10:40:17
    Repository https://git.tcpdump.org/libpcap
    Project libpcap
    Branch master
    Revision e2fe69377b84cf5e963b54946cb616cfbc4a76d4

    Comments

    Indicate no-capture and no-inject devices.
Introduce PCAP_IF_NO_CAPTURE and PCAP_IF_NO_INJECT interface flags.  Set
PCAP_IF_NO_INJECT on Bluetooth, DAG Rx stream, Haiku network interfaces,
Linux netfilter, RDMA, Linux USB and the "any" pseudo-interface devices.
Set PCAP_IF_NO_CAPTURE on DAG Tx stream devices.  Update related man
pages and findalldevstest.

    Changed files

    • CHANGES
    • pcap-bt-linux.c
    • pcap-bt-monitor-linux.c
    • pcap-dag.c
    • pcap-haiku.c
    • pcap-netfilter-linux.c
    • pcap-rdmasniff.c
    • pcap-usb-linux.c
    • pcap.c
    • pcap/pcap.h
    • pcap_activate.3pcap
    • pcap_findalldevs.3pcap
    • pcap_inject.3pcap
    • testprogs/findalldevstest.c
BuildBot (0.8.14) working for the OpenCSW Buildbot project.
Page built: Thu 15 Oct 2026 23:31:48 (CEST)