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

Builder memcached-solaris10-i386 Build #218

Results:

Failed shell_2 shell_3

SourceStamp:

Projectmemcached
Repositorygit://github.com/memcached/memcached.git
Branchnext
Revisionfa40655b49cc73194acc0e2410930f3e9a8322a7
Got Revisionfa40655b49cc73194acc0e2410930f3e9a8322a7
Changes1 change

BuildSlave:

unstable10x

Reason:

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

Steps and Logfiles:

  1. git update ( 2 secs )
    1. stdio
  2. shell 'bash autogen.sh' ( 6 secs )
    1. stdio
  3. shell_1 './configure --enable-sasl ...' ( 16 secs )
    1. stdio
    2. config.log
  4. shell_2 'gmake' failed ( 1 secs )
    1. stdio
  5. shell_3 'gmake test' failed ( 0 secs )
    1. stdio

Build Properties:

NameValueSource
branch next Build
builddir /export/home/buildbot/slave/memcached-solaris10-i386 slave
buildername memcached-solaris10-i386 Builder
buildnumber 218 Build
codebase Build
got_revision fa40655b49cc73194acc0e2410930f3e9a8322a7 Git
project memcached Build
repository git://github.com/memcached/memcached.git Build
revision fa40655b49cc73194acc0e2410930f3e9a8322a7 Build
scheduler schedule-memcached-solaris10-i386 Scheduler
slavename unstable10x BuildSlave
workdir /export/home/buildbot/slave/memcached-solaris10-i386 slave (deprecated)

Forced Build Properties:

NameLabelValue

Responsible Users:

  1. dormando

Timing:

StartThu Mar 26 20:05:04 2020
EndThu Mar 26 20:05:32 2020
Elapsed28 secs

All Changes:

:

  1. Change #102719

    Category memcached
    Changed by dormando <dormandoohnoyoudont@rydia.net>
    Changed at Thu 26 Mar 2020 19:59:22
    Repository git://github.com/memcached/memcached.git
    Project memcached
    Branch next
    Revision fa40655b49cc73194acc0e2410930f3e9a8322a7

    Comments

    restart: fix corrupted restart in some scenarios
    If the mmap file is reused but the memory isn't supposed to be reused,
    pages are thrown into the global page pool. Normally when pages are
    released into the pool the header of the page is zero'ed so the
    restart_check() code will know to place it back into the global pool.
    
    When restarting multiple times the slabs_prefill() part of the startup
    code was missing this zero'ing step, so the _next_ time restart happens
    properly restart_check() could attempt to recover that memory.

    Changed files

    • slabs.c