From renato at luren.com.br  Thu Aug  5 17:18:16 2010
From: renato at luren.com.br (Renato Farias)
Date: Thu, 5 Aug 2010 14:18:16 -0300 (BRT)
Subject: [Varnish] #745: Varnishstat
Message-ID: <t2tih2a.37f5343f4a69a9b62964ab5df4e7737d@webmail.luren.com.br>

Hi Yves,

I don't think so.

Cause the "Total body bytes" numbers stay ok.

I've read in some forums and I've encountered some users with the same problem.

Have any config that I can send for more better investigation?

Att,

Renato Farias

>---- Original Message ----
>From: "Varnish" <varnish-bugs at varnish-cache.org>
>To: renato at luren.com.br, phk at phk.freebsd.dk, yves at varnish-software.com
>Cc: varnish-bugs at varnish-cache.org
>Sent: Thu, Aug 5, 2010, 5:26 AM
>Subject: Re: [Varnish] #745: Varnishstat
>
>#745: Varnishstat
>--------------------------+-------------------------------------------------
> Reporter:  piripirigoso  |       Owner:  phk                
>     Type:  defect        |      Status:  new                
> Priority:  high          |   Milestone:  Varnish 2.1 release
>Component:  varnishstat   |     Version:  2.1.2              
> Severity:  critical      |    Keywords:  varnishstats       
>--------------------------+-------------------------------------------------
>
>Comment(by yves):
>
> Hi,
>
>
> It appears that the Varnish worker process is being restarted thus
> resetting the varnishstat back to zero. In order to locate the cause of
> this, I would kindly ask that you attach any entries in the syslog
> containing panic messages relating to crahses/kills. This will help
> greatly.
>
>
> regards,
>
> Yves
>
>-- 
>Ticket URL: <http://www.varnish-cache.org/ticket/745#comment:1>
>Varnish <http://varnish-cache.org/>
>The Varnish HTTP Accelerator




From renato at luren.com.br  Thu Aug  5 20:51:28 2010
From: renato at luren.com.br (Renato Farias)
Date: Thu, 5 Aug 2010 17:51:28 -0300 (BRT)
Subject: Varnish Craches
Message-ID: <t2tih2a.f6c8741562fbc16b6ba9f4bb2b2745da@webmail.luren.com.br>

An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-bugs/attachments/20100805/86052205/attachment.html>

From tfheen at varnish-software.com  Tue Aug 10 08:20:21 2010
From: tfheen at varnish-software.com (Tollef Fog Heen)
Date: Tue, 10 Aug 2010 10:20:21 +0200
Subject: Varnish Craches
In-Reply-To: <t2tih2a.f6c8741562fbc16b6ba9f4bb2b2745da@webmail.luren.com.br>
	(Renato Farias's message of "Thu, 5 Aug 2010 17:51:28 -0300 (BRT)")
References: <t2tih2a.f6c8741562fbc16b6ba9f4bb2b2745da@webmail.luren.com.br>
Message-ID: <87tyn2j2uy.fsf@qurzaw.linpro.no>

]] "Renato Farias" 

Hi,

|    My installation's Varnish, has shown the following error:


[...]

|    Any Ideia?

Could you please file this in trac so we can track it properly?

Thanks,
-- 
Tollef Fog Heen
Varnish Software
t: +47 21 54 41 73



From varnish-bugs at varnish-cache.org  Mon Aug  2 17:23:05 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 02 Aug 2010 17:23:05 -0000
Subject: [Varnish] #746: Varnish keep crashing since i use pipe
Message-ID: <044.aca684cffee52eac0f54f3107612f40f@varnish-cache.org>

#746: Varnish keep crashing since i use pipe
----------------------+-----------------------------------------------------
 Reporter:  ccastro   |       Owner:  phk        
     Type:  defect    |      Status:  new        
 Priority:  high      |   Milestone:             
Component:  varnishd  |     Version:  trunk      
 Severity:  normal    |    Keywords:  pipe, 2.1.3
----------------------+-----------------------------------------------------
 I was force to use pipe, for a php script, and since then varnish keep
 crashing (every 5 minutes), i was using 2.0.1 and now 2.1.3, but the
 behavior persist.

  Child (28957) Panic message: Assert error in TCP_close(), tcp.c line 243:
 Condition(TCP_Check(i)) not true. errno = 22 (Invalid argument) thread =
 (cache-worker) ident =
 FreeBSD,6.2-RELEASE-p9,amd64,-sfile,-hcritbit,kqueue sp = 0x4620008 {   fd
 = -1, id = 316, xid = 949279634,   client = 200.126.95.205:1375,   step =
 STP_PIPE,   handling = pipe,   restarts = 0, esis = 0   ws = 0x4620078 {
 id = "sess",     {s,f,r,e} = {0x4620cc0,+464,0x0,+65536},   },   http[req]
 = {     ws = 0x4620078[sess]       "GET",
 "/ads2/ads2.clk?ts=20100720111116&cli=admin&url=http%3A//www.mbauach.cl/",
 "HTTP/1.1",       "Accept: */*",       "Referer: http://www.xxx/xx.html",
 "Accept-Language: es",       "User-Agent: Mozilla/4.0 (compatible; MSIE
 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; uE v7; InfoPath.2;
 .NET CLR 2.0.50727; uE v7)",       "Accept-Encoding: gzip, deflate",
 "Host: portada.diariosregi


 This error repeats for different URLs and different clients.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/746>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug  4 10:18:59 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 04 Aug 2010 10:18:59 -0000
Subject: [Varnish] #746: Varnish keep crashing since i use pipe
In-Reply-To: <044.aca684cffee52eac0f54f3107612f40f@varnish-cache.org>
References: <044.aca684cffee52eac0f54f3107612f40f@varnish-cache.org>
Message-ID: <053.595dd08dd196f00ed107d1b4ae06d3cf@varnish-cache.org>

#746: Varnish keep crashing since i use pipe
----------------------+-----------------------------------------------------
 Reporter:  ccastro   |       Owner:  phk        
     Type:  defect    |      Status:  new        
 Priority:  high      |   Milestone:             
Component:  varnishd  |     Version:  trunk      
 Severity:  normal    |    Keywords:  pipe, 2.1.3
----------------------+-----------------------------------------------------
Description changed by phk:

Old description:

> I was force to use pipe, for a php script, and since then varnish keep
> crashing (every 5 minutes), i was using 2.0.1 and now 2.1.3, but the
> behavior persist.
>
>  Child (28957) Panic message: Assert error in TCP_close(), tcp.c line
> 243:   Condition(TCP_Check(i)) not true. errno = 22 (Invalid argument)
> thread = (cache-worker) ident =
> FreeBSD,6.2-RELEASE-p9,amd64,-sfile,-hcritbit,kqueue sp = 0x4620008 {
> fd = -1, id = 316, xid = 949279634,   client = 200.126.95.205:1375,
> step = STP_PIPE,   handling = pipe,   restarts = 0, esis = 0   ws =
> 0x4620078 {      id = "sess",     {s,f,r,e} =
> {0x4620cc0,+464,0x0,+65536},   },   http[req] = {     ws =
> 0x4620078[sess]       "GET",
> "/ads2/ads2.clk?ts=20100720111116&cli=admin&url=http%3A//www.mbauach.cl/",
> "HTTP/1.1",       "Accept: */*",       "Referer: http://www.xxx/xx.html",
> "Accept-Language: es",       "User-Agent: Mozilla/4.0 (compatible; MSIE
> 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; uE v7; InfoPath.2;
> .NET CLR 2.0.50727; uE v7)",       "Accept-Encoding: gzip, deflate",
> "Host: portada.diariosregi
>

> This error repeats for different URLs and different clients.

New description:

 I was force to use pipe, for a php script, and since then varnish keep
 crashing (every 5 minutes), i was using 2.0.1 and now 2.1.3, but the
 behavior persist.

 {{{
  Child (28957)
  Panic message: Assert error in TCP_close(), tcp.c line 243:
    Condition(TCP_Check(i)) not true. errno = 22 (Invalid argument)
  thread = (cache-worker)
  ident = FreeBSD,6.2-RELEASE-p9,amd64,-sfile,-hcritbit,kqueue
  sp = 0x4620008 {
    fd = -1, id = 316, xid = 949279634,
    client = 200.126.95.205:1375,
    step = STP_PIPE,
    handling = pipe,
    restarts = 0, esis = 0
    ws = 0x4620078 {
       id = "sess",
      {s,f,r,e} = {0x4620cc0,+464,0x0,+65536},
    },
    http[req] = {
      ws = 0x4620078[sess]
        "GET",
 "/ads2/ads2.clk?ts=20100720111116&cli=admin&url=http%3A//www.mbauach.cl/",
        "HTTP/1.1",
        "Accept: */*",
        "Referer: http://www.xxx/xx.html",
        "Accept-Language: es",
        "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;
 Trident/4.0; .NET CLR 1.1.4322; uE v7; InfoPath.2; .NET CLR 2.0.50727; uE
 v7)",
        "Accept-Encoding: gzip, deflate",
        "Host: portada.diariosregi
 }}}

 This error repeats for different URLs and different clients.

--

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/746#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug  4 10:25:31 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 04 Aug 2010 10:25:31 -0000
Subject: [Varnish] #737: ExpKILL
In-Reply-To: <044.74ce0b6b8dd77e901938a6c929ff024a@varnish-cache.org>
References: <044.74ce0b6b8dd77e901938a6c929ff024a@varnish-cache.org>
Message-ID: <053.ef2d5f039efb817d3be5b64a9e84d40f@varnish-cache.org>

#737: ExpKILL
----------------------+-----------------------------------------------------
 Reporter:  Rodrigo   |       Owner:  phk                
     Type:  defect    |      Status:  new                
 Priority:  highest   |   Milestone:  Varnish 2.1 release
Component:  varnishd  |     Version:  2.1.2              
 Severity:  blocker   |    Keywords:                     
----------------------+-----------------------------------------------------
Description changed by phk:

Old description:

> I am using Varnish 2.1.2 and I am getting this error on Varnishlog which
> is causing me 503's
>

>   0 ExpKill      - 476131785 -60
>     0 ExpKill      - 476131786 -60
>     0 ExpKill      - 476131788 -60
>     0 ExpKill      - 476131789 -60
>     0 ExpKill      - 476131790 -60
>     0 ExpKill      - 475778248 -60
>     0 ExpKill      - 476131794 -60
>     0 ExpKill      - 476131796 -60
>     0 ExpKill      - 476131799 -60
>     0 ExpKill      - 476131800 -60
>     0 ExpKill      - 476131804 -60
>     0 ExpKill      - 476131809 -60
>     0 ExpKill      - 476131814 -60
>     0 ExpKill      - 476131817 -60
>     0 ExpKill      - 476131821 -60
>     0 CLI          - Rd ping
>     0 CLI          - Wr 200 PONG 1279724710 1.0
>     0 ExpKill      - 476131825 -60
>     0 ExpKill      - 476131827 -60
>     0 ExpKill      - 476131837 -60
>     0 ExpKill      - 476131840 -60
>     0 ExpKill      - 476131841 -60
>     0 ExpKill      - 476131847 -60
>     0 ExpKill      - 476131859 -60
>     0 ExpKill      - 476131861 -60
>     0 ExpKill      - 476131862 -60
>     0 ExpKill      - 476131867 -60
>     0 ExpKill      - 476131873 -60
>     0 ExpKill      - 476131886 -60
>     0 ExpKill      - 476131889 -60
>     0 ExpKill      - 476131890 -60
>     0 ExpKill      - 476131892 -60
>     0 ExpKill      - 476131895 -60
>     0 ExpKill      - 476131911 -60
>     0 ExpKill      - 476131915 -60
>     0 ExpKill      - 476131916 -60
>     0 ExpKill      - 476131919 -60
>     0 ExpKill      - 476131921 -60
>     0 ExpKill      - 476131925 -60
>     0 ExpKill      - 476131937 -60
>     0 ExpKill      - 476131977 -60
>     0 ExpKill      - 476131979 -60
>     0 ExpKill      - 475778294 -60
>     0 ExpKill      - 475778296 -60
>     0 ExpKill      - 475778297 -60
>     0 ExpKill      - 476131986 -60
>     0 ExpKill      - 476131995 -60
>     0 ExpKill      - 475778300 -60
>     0 ExpKill      - 476131996 -60
>     0 ExpKill      - 476132000 -60
>     0 ExpKill      - 475778301 -60
>     0 ExpKill      - 476132003 -60
>     0 ExpKill      - 475778306 -60
>     0 ExpKill      - 476132014 -60
>     0 ExpKill      - 475778310 -60
>     0 ExpKill      - 476132018 -60
>     0 ExpKill      - 476132025 -60
>     0 ExpKill      - 476132033 -60
>

> I cant seem to figure what error means or how to delete it.
>
> This is my VarnishStat
>

> 0+20:07:37
> var01.buscacorp.com
> Hitrate ratio:       10       21       21
> Hitrate avg:     0.7285   0.7310   0.7310
>
>      1116301        17.99        15.41 Client connections accepted
>      4520884        68.95        62.39 Client requests received
>      2930655        44.97        40.45 Cache hits
>        17132         0.00         0.24 Cache hits for pass
>      1049494        15.99        14.48 Cache misses
>       421592         5.00         5.82 Backend conn. success
>      1165918        17.99        16.09 Backend conn. reuses
>       212016         4.00         2.93 Backend conn. was closed
>      1377945        21.99        19.02 Backend conn. recycles
>        14399         0.00         0.20 Fetch head
>      1231700        19.99        17.00 Fetch with Length
>       211378         4.00         2.92 Fetch chunked
>          882         0.00         0.01 Fetch wanted close
>            2         0.00         0.00 Fetch failed
>         1296          .            .   N struct sess_mem
>          627          .            .   N struct sess
>        55201          .            .   N struct object
>        55295          .            .   N struct objectcore
>        74700          .            .   N struct objecthead
>       112304          .            .   N struct smf
>         1434          .            .   N small free smf
>          579          .            .   N large free smf
>           60          .            .   N struct vbe_conn
>          136          .            .   N worker threads
>         1782         0.00         0.02 N worker threads created
>            0         0.00         0.00 N queued work requests
>        21538         0.00         0.30 N overflowed work requests
>            5          .            .   N backends
>       834374          .            .   N expired objects
>      2515582          .            .   N LRU moved objects
>      3738560        62.96        51.60 Objects sent with write
>      1116253        17.99        15.41 Total Sessions
>      4520884        68.95        62.39 Total Requests
>       131009         0.00         1.81 Total pipe
>       414748         7.99         5.72 Total pass
>      1452908        23.98        20.05 Total fetch
>   1585032626     22456.93     21875.49 Total header bytes
> 216833013960   2798777.61   2992575.10 Total body bytes
>       360740         6.00         4.98 Session Closed
>         7115         0.00         0.10 Session Pipeline
>        10786         0.00         0.15 Session Read Ahead
>      4249623        65.96        58.65 Session Linger
>      4281093        62.96        59.08 Session herd
>    234483085      3585.59      3236.17 SHM records
>     15282489       223.85       210.92 SHM writes
>          907         0.00         0.01 SHM flushes due to overflow
>        37899         0.00         0.52 SHM MTX contention
>          105         0.00         0.00 SHM cycles through buffer
>      2282435        35.98        31.50 allocator requests
>       110291          .            .   outstanding allocations
>   4452687872          .            .   bytes allocated
>   6284730368          .            .   bytes free
>         6310         0.00         0.09 SMS allocator requests
>      3075346          .            .   SMS bytes allocated
>      3075346          .            .   SMS bytes freed
>      1458409        21.99        20.13 Backend requests made

New description:

 I am using Varnish 2.1.2 and I am getting this error on Varnishlog which
 is causing me 503's

 {{{
   0 ExpKill      - 476131785 -60
     0 ExpKill      - 476131786 -60
     0 ExpKill      - 476131788 -60
     0 ExpKill      - 476131789 -60
     0 ExpKill      - 476131790 -60
     0 ExpKill      - 475778248 -60
     0 ExpKill      - 476131794 -60
     0 ExpKill      - 476131796 -60
     0 ExpKill      - 476131799 -60
     0 ExpKill      - 476131800 -60
     0 ExpKill      - 476131804 -60
     0 ExpKill      - 476131809 -60
     0 ExpKill      - 476131814 -60
     0 ExpKill      - 476131817 -60
     0 ExpKill      - 476131821 -60
     0 CLI          - Rd ping
     0 CLI          - Wr 200 PONG 1279724710 1.0
     0 ExpKill      - 476131825 -60
     0 ExpKill      - 476131827 -60
     0 ExpKill      - 476131837 -60
     0 ExpKill      - 476131840 -60
     0 ExpKill      - 476131841 -60
     0 ExpKill      - 476131847 -60
     0 ExpKill      - 476131859 -60
     0 ExpKill      - 476131861 -60
     0 ExpKill      - 476131862 -60
     0 ExpKill      - 476131867 -60
     0 ExpKill      - 476131873 -60
     0 ExpKill      - 476131886 -60
     0 ExpKill      - 476131889 -60
     0 ExpKill      - 476131890 -60
     0 ExpKill      - 476131892 -60
     0 ExpKill      - 476131895 -60
     0 ExpKill      - 476131911 -60
     0 ExpKill      - 476131915 -60
     0 ExpKill      - 476131916 -60
     0 ExpKill      - 476131919 -60
     0 ExpKill      - 476131921 -60
     0 ExpKill      - 476131925 -60
     0 ExpKill      - 476131937 -60
     0 ExpKill      - 476131977 -60
     0 ExpKill      - 476131979 -60
     0 ExpKill      - 475778294 -60
     0 ExpKill      - 475778296 -60
     0 ExpKill      - 475778297 -60
     0 ExpKill      - 476131986 -60
     0 ExpKill      - 476131995 -60
     0 ExpKill      - 475778300 -60
     0 ExpKill      - 476131996 -60
     0 ExpKill      - 476132000 -60
     0 ExpKill      - 475778301 -60
     0 ExpKill      - 476132003 -60
     0 ExpKill      - 475778306 -60
     0 ExpKill      - 476132014 -60
     0 ExpKill      - 475778310 -60
     0 ExpKill      - 476132018 -60
     0 ExpKill      - 476132025 -60
     0 ExpKill      - 476132033 -60
 }}}

 I cant seem to figure what error means or how to delete it.

 This is my VarnishStat

 {{{
 0+20:07:37
 var01.buscacorp.com
 Hitrate ratio:       10       21       21
 Hitrate avg:     0.7285   0.7310   0.7310

      1116301        17.99        15.41 Client connections accepted
      4520884        68.95        62.39 Client requests received
      2930655        44.97        40.45 Cache hits
        17132         0.00         0.24 Cache hits for pass
      1049494        15.99        14.48 Cache misses
       421592         5.00         5.82 Backend conn. success
      1165918        17.99        16.09 Backend conn. reuses
       212016         4.00         2.93 Backend conn. was closed
      1377945        21.99        19.02 Backend conn. recycles
        14399         0.00         0.20 Fetch head
      1231700        19.99        17.00 Fetch with Length
       211378         4.00         2.92 Fetch chunked
          882         0.00         0.01 Fetch wanted close
            2         0.00         0.00 Fetch failed
         1296          .            .   N struct sess_mem
          627          .            .   N struct sess
        55201          .            .   N struct object
        55295          .            .   N struct objectcore
        74700          .            .   N struct objecthead
       112304          .            .   N struct smf
         1434          .            .   N small free smf
          579          .            .   N large free smf
           60          .            .   N struct vbe_conn
          136          .            .   N worker threads
         1782         0.00         0.02 N worker threads created
            0         0.00         0.00 N queued work requests
        21538         0.00         0.30 N overflowed work requests
            5          .            .   N backends
       834374          .            .   N expired objects
      2515582          .            .   N LRU moved objects
      3738560        62.96        51.60 Objects sent with write
      1116253        17.99        15.41 Total Sessions
      4520884        68.95        62.39 Total Requests
       131009         0.00         1.81 Total pipe
       414748         7.99         5.72 Total pass
      1452908        23.98        20.05 Total fetch
   1585032626     22456.93     21875.49 Total header bytes
 216833013960   2798777.61   2992575.10 Total body bytes
       360740         6.00         4.98 Session Closed
         7115         0.00         0.10 Session Pipeline
        10786         0.00         0.15 Session Read Ahead
      4249623        65.96        58.65 Session Linger
      4281093        62.96        59.08 Session herd
    234483085      3585.59      3236.17 SHM records
     15282489       223.85       210.92 SHM writes
          907         0.00         0.01 SHM flushes due to overflow
        37899         0.00         0.52 SHM MTX contention
          105         0.00         0.00 SHM cycles through buffer
      2282435        35.98        31.50 allocator requests
       110291          .            .   outstanding allocations
   4452687872          .            .   bytes allocated
   6284730368          .            .   bytes free
         6310         0.00         0.09 SMS allocator requests
      3075346          .            .   SMS bytes allocated
      3075346          .            .   SMS bytes freed
      1458409        21.99        20.13 Backend requests made
 }}}

--

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/737#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug  4 10:29:21 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 04 Aug 2010 10:29:21 -0000
Subject: [Varnish] #732: Varnish apparently does not allow for cross
	compiling
In-Reply-To: <043.4a11dbf6026761e50f72455b6dc4a0cd@varnish-cache.org>
References: <043.4a11dbf6026761e50f72455b6dc4a0cd@varnish-cache.org>
Message-ID: <052.ea9992e726a252ca494f2f3f65f5a30e@varnish-cache.org>

#732: Varnish apparently does not allow for cross compiling
-------------------------+--------------------------------------------------
  Reporter:  ccrumb      |        Type:  defect
    Status:  closed      |    Priority:  normal
 Milestone:              |   Component:  build 
   Version:  trunk       |    Severity:  normal
Resolution:  worksforme  |    Keywords:        
-------------------------+--------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => worksforme


Old description:

> Was going to try cross compiling Varnish for ARM and did the following:
>
> ./configure --target=arm-none-linux-gnueabi --host=arm-none-linux-gnueabi
>
> Ended up with a message:
> checking whether SO_RCVTIMEO works... configure: error: cannot run test
> program while cross compiling
>
> Is there any particular reason not to allow/support cross compilation?

New description:

 Was going to try cross compiling Varnish for ARM and did the following:

 ./configure --target=arm-none-linux-gnueabi --host=arm-none-linux-gnueabi

 Ended up with a message:
 checking whether SO_RCVTIMEO works... configure: error: cannot run test
 program while cross compiling

 Is there any particular reason not to allow/support cross compilation?

--

Comment:

 Varnish needs a C compiler at runtime, so the usual benefit of cross-
 compiling (Saving a tool-chain) does not apply.

 We perform a number of auto* tests to figure out stuff about the platfrom,
 like  the RCVTIMEO test, you would have to provide correct specification
 of those details if you want to cross-compile.

 Otherwise there shouldn't really be anything impossible about it, but
 since Varnish needs a C compiler at runtime, the usual benefit of cross-
 compiling (Saving a tool-chain) does not apply.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/732#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug  4 10:39:01 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 04 Aug 2010 10:39:01 -0000
Subject: [Varnish] #736: Migration to Cygwin plataform
In-Reply-To: <042.6ef2981e8cf7eb068adf1551551220f4@varnish-cache.org>
References: <042.6ef2981e8cf7eb068adf1551551220f4@varnish-cache.org>
Message-ID: <051.1f23c665fb9f10a3a8226647e4304107@varnish-cache.org>

#736: Migration to Cygwin plataform
----------------------+-----------------------------------------------------
  Reporter:  jdzst    |        Type:  enhancement    
    Status:  closed   |    Priority:  normal         
 Milestone:           |   Component:  build          
   Version:           |    Severity:  normal         
Resolution:  invalid  |    Keywords:  cygwin, windows
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => invalid


Comment:

 Your ticket and work with cygwin caused me to ponder what we mean by
 "supported platform" in Varnish, and I wrote up my thoughts yesterday:

 http://varnish-cache.org/browser/trunk/varnish-
 cache/doc/sphinx/phk/platforms.rst

 CYGWIN is a Tier C platform, one we are willing to tolerate, if it does
 not cost us too much effort.

 These changes do not look terribly intrusive.  (I don't understand why you
 have to modify all the Makefile.am to add cygwin specific LD-flags, I
 thought autocrap did that for you ?)

 On the other hand, you don't seem to have managed to get much
 functionality out of it yet, given that some of those failing tests are
 very basic functionality.

 But keep at it, send us patches instead of complete files, once you get
 the test-cases to work, and we will give you a fair reading.

 For now I will close this ticket.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/736#comment:7>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug  4 11:46:38 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 04 Aug 2010 11:46:38 -0000
Subject: [Varnish] #737: ExpKILL
In-Reply-To: <044.74ce0b6b8dd77e901938a6c929ff024a@varnish-cache.org>
References: <044.74ce0b6b8dd77e901938a6c929ff024a@varnish-cache.org>
Message-ID: <053.9da76e71b4d1b305ad00a7a8c54811a6@varnish-cache.org>

#737: ExpKILL
----------------------+-----------------------------------------------------
 Reporter:  Rodrigo   |        Owner:  phk                
     Type:  defect    |       Status:  closed             
 Priority:  highest   |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  2.1.2              
 Severity:  blocker   |   Resolution:  invalid            
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by kristian):

  * status:  new => closed
  * resolution:  => invalid


Comment:

 The ExpKill messages are normal, and just an indication of old content
 expiring. This is not an error.

 The varnishstat output also just has two fetch failures for the last 20
 hours, which doesn't look horribly bad.

 As we don't believe this is a bug, I'm closing the report. I suggest that
 you use the varnish-misc mail list, as there are far more people reading
 that, than this bug tracker anyway. You may want to supply some output of
 'varnishlog -c -o TxStatus 503' though, to get more information.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/737#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug  4 12:40:48 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 04 Aug 2010 12:40:48 -0000
Subject: [Varnish] #743: Modification to varnishncsa init script on RH
	based distros
In-Reply-To: <043.1837d707016f590252ca8d7dd1dd7354@varnish-cache.org>
References: <043.1837d707016f590252ca8d7dd1dd7354@varnish-cache.org>
Message-ID: <052.2236611c78c9559536d7dd8e18405031@varnish-cache.org>

#743: Modification to varnishncsa init script on  RH based distros
----------------------+-----------------------------------------------------
  Reporter:  jlintz   |        Type:  defect   
    Status:  closed   |    Priority:  normal   
 Milestone:           |   Component:  packaging
   Version:  2.0      |    Severity:  normal   
Resolution:  invalid  |    Keywords:  epel rpm 
----------------------+-----------------------------------------------------
Changes (by tfheen):

  * status:  new => closed
  * resolution:  => invalid


Comment:

 While it's correct that you can't override just $logfile from the
 sysconfig file, what you should do is set DAEMON_OPTS to the desired
 value.

 If we move where the sysconfig file is sourced, that would prevent you
 from overriding DAEMON_OPTS if you wanted to set any other options than
 the ones we set by default.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/743#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug  4 12:49:02 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 04 Aug 2010 12:49:02 -0000
Subject: [Varnish] #740: Build dependencies on Debian/Ubuntu should
	mention pkg-config
In-Reply-To: <045.d15ba4b4913c446c52cb4d721a65f5b5@varnish-cache.org>
References: <045.d15ba4b4913c446c52cb4d721a65f5b5@varnish-cache.org>
Message-ID: <054.d5870083f8124e9c34357da5cf574f99@varnish-cache.org>

#740: Build dependencies on Debian/Ubuntu should mention pkg-config
-----------------------+----------------------------------------------------
  Reporter:  arrowman  |        Type:  defect       
    Status:  closed    |    Priority:  normal       
 Milestone:            |   Component:  documentation
   Version:  2.1.0     |    Severity:  minor        
Resolution:  fixed     |    Keywords:               
-----------------------+----------------------------------------------------
Changes (by tfheen):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 (In [5070]) Mention pkg-config in build requirements too

 Fixes #740

-- 
Ticket URL: </ticket/740#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug  4 13:20:24 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 04 Aug 2010 13:20:24 -0000
Subject: [Varnish] #698: High load after upgrade from 2.1.0 to 2.1.2
In-Reply-To: <052.f68f3643429fb7a3ce7506fd69c3306f@varnish-cache.org>
References: <052.f68f3643429fb7a3ce7506fd69c3306f@varnish-cache.org>
Message-ID: <061.d3efe78288e72555867dcab4b6c415af@varnish-cache.org>

#698: High load after upgrade from 2.1.0 to 2.1.2
------------------------------+---------------------------------------------
  Reporter:  lukasz.jagiello  |        Type:  defect
    Status:  closed           |    Priority:  normal
 Milestone:                   |   Component:  build 
   Version:  trunk            |    Severity:  normal
Resolution:  fixed            |    Keywords:        
------------------------------+---------------------------------------------
Changes (by kristian):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 We believe we nailed this with 2.1.3. We've seen similar reports and those
 were resolved with 2.1.3.

 I'm closing this under the presumption that it's solved. Feel free to re-
 open if this persists after upgrading to 2.1.3.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/698#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug  4 13:31:04 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 04 Aug 2010 13:31:04 -0000
Subject: [Varnish] #743: Modification to varnishncsa init script on RH
	based distros
In-Reply-To: <043.1837d707016f590252ca8d7dd1dd7354@varnish-cache.org>
References: <043.1837d707016f590252ca8d7dd1dd7354@varnish-cache.org>
Message-ID: <052.1cd63a0ab81bd7d1d1feaaf6975dd570@varnish-cache.org>

#743: Modification to varnishncsa init script on  RH based distros
----------------------+-----------------------------------------------------
  Reporter:  jlintz   |        Type:  defect   
    Status:  closed   |    Priority:  normal   
 Milestone:           |   Component:  packaging
   Version:  2.0      |    Severity:  normal   
Resolution:  invalid  |    Keywords:  epel rpm 
----------------------+-----------------------------------------------------

Comment(by jlintz):

 Wouldn't the best option be then to have the default DAEMON_OPTS in
 /etc/sysconfig/varnishncsa , and out of the init script?  That way users
 can modify both the default log file and daemon_opts without modifying the
 init script.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/743#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug  4 13:36:29 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 04 Aug 2010 13:36:29 -0000
Subject: [Varnish] #746: Varnish keep crashing since i use pipe
In-Reply-To: <044.aca684cffee52eac0f54f3107612f40f@varnish-cache.org>
References: <044.aca684cffee52eac0f54f3107612f40f@varnish-cache.org>
Message-ID: <053.87f8d4f071d99843a0fba5845aade089@varnish-cache.org>

#746: Varnish keep crashing since i use pipe
----------------------+-----------------------------------------------------
 Reporter:  ccastro   |       Owner:  martin     
     Type:  defect    |      Status:  new        
 Priority:  high      |   Milestone:             
Component:  varnishd  |     Version:  trunk      
 Severity:  normal    |    Keywords:  pipe, 2.1.3
----------------------+-----------------------------------------------------
Changes (by martin):

  * owner:  phk => martin


-- 
Ticket URL: <http://www.varnish-cache.org/ticket/746#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug  4 13:37:36 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 04 Aug 2010 13:37:36 -0000
Subject: [Varnish] #739: varnishlog sometimes reports backend logs as
	client logs
In-Reply-To: <043.60537f3fd7d53c8366decae348d0ce4c@varnish-cache.org>
References: <043.60537f3fd7d53c8366decae348d0ce4c@varnish-cache.org>
Message-ID: <052.ddeb1b2a53fbb067a7799070cb0b2923@varnish-cache.org>

#739: varnishlog sometimes reports backend logs as client logs
------------------------+---------------------------------------------------
 Reporter:  thoran      |       Owner:  martin
     Type:  defect      |      Status:  new   
 Priority:  normal      |   Milestone:        
Component:  varnishlog  |     Version:  2.1.2 
 Severity:  major       |    Keywords:        
------------------------+---------------------------------------------------
Changes (by martin):

  * owner:  phk => martin


-- 
Ticket URL: <http://www.varnish-cache.org/ticket/739#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug  4 15:06:48 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 04 Aug 2010 15:06:48 -0000
Subject: [Varnish] #698: High load after upgrade from 2.1.0 to 2.1.2
In-Reply-To: <052.f68f3643429fb7a3ce7506fd69c3306f@varnish-cache.org>
References: <052.f68f3643429fb7a3ce7506fd69c3306f@varnish-cache.org>
Message-ID: <061.f8fa1a520d053649298c0ad6762e6526@varnish-cache.org>

#698: High load after upgrade from 2.1.0 to 2.1.2
------------------------------+---------------------------------------------
  Reporter:  lukasz.jagiello  |        Type:  defect
    Status:  closed           |    Priority:  normal
 Milestone:                   |   Component:  build 
   Version:  trunk            |    Severity:  normal
Resolution:  fixed            |    Keywords:        
------------------------------+---------------------------------------------

Comment(by lukasz.jagiello):

 After few hours testing everything looks ok.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/698#comment:4>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug  4 15:46:29 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 04 Aug 2010 15:46:29 -0000
Subject: [Varnish] #731: Can't remove illegal header without terminal colon
In-Reply-To: <042.2bedc9032a3afd45a69e919dde5311df@varnish-cache.org>
References: <042.2bedc9032a3afd45a69e919dde5311df@varnish-cache.org>
Message-ID: <051.7c56710fbee378175b17d32cbe9943b5@varnish-cache.org>

#731: Can't remove illegal header without terminal colon
-------------------------+--------------------------------------------------
  Reporter:  slink       |        Type:  defect
    Status:  closed      |    Priority:  normal
 Milestone:              |   Component:  build 
   Version:  trunk       |    Severity:  normal
Resolution:  worksforme  |    Keywords:        
-------------------------+--------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => worksforme


Comment:

 I am going to pass on this one.

 Your client is clearly broken, there is no way I can read RFC2616 to allow
 usage of continuation lines for fields in the first line.

 I am not going to butcher varnish error checks for the sake of one broken
 client somewhere, sorry.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/731#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug  4 15:49:47 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 04 Aug 2010 15:49:47 -0000
Subject: [Varnish] #735: Support backend control via CLI
In-Reply-To: <040.5238d8dc11accb237444ccdefb404199@varnish-cache.org>
References: <040.5238d8dc11accb237444ccdefb404199@varnish-cache.org>
Message-ID: <049.30f046e1c0c97bd56abde5e724014374@varnish-cache.org>

#735: Support backend control via CLI
-------------------------+--------------------------------------------------
 Reporter:  tgr          |        Owner:  phk    
     Type:  enhancement  |       Status:  closed 
 Priority:  normal       |    Milestone:         
Component:  varnishd     |      Version:  trunk  
 Severity:  normal       |   Resolution:  invalid
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => invalid


Comment:

 It is a good idea, but it runs into the same naming issue as many other
 backend related features and therefore I will not take the patch as is.

 I have moved this to the PostTwoShoppingList with the other change
 requests.

 I have promised myself to get that naming issue sorted out before 3.0

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/735#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug  4 15:54:39 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 04 Aug 2010 15:54:39 -0000
Subject: [Varnish] #738: New functionality: loading a compiled VCL SO
	library file at boot
In-Reply-To: <042.26d3c22cd66586f9ea2e069d9409993a@varnish-cache.org>
References: <042.26d3c22cd66586f9ea2e069d9409993a@varnish-cache.org>
Message-ID: <051.0be2070c299ed7199cb09f0fd755a2d1@varnish-cache.org>

#738: New functionality: loading a compiled VCL SO library file at boot
-------------------------+--------------------------------------------------
 Reporter:  jdzst        |        Owner:  phk    
     Type:  enhancement  |       Status:  closed 
 Priority:  low          |    Milestone:         
Component:  varnishd     |      Version:         
 Severity:  normal       |   Resolution:  wontfix
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => wontfix


Comment:

 Sorry, but I am not going to adopt this idea.

 The main argument against is that this opens us up to major version-skew
 between the precompiled VCL and varnishd and that is far more trouble
 catching, than the benefits you list.

 As for attackers executing your c-compiler:  To do that, your CLI is must
 be compromised and that is the barrier you really should defend.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/738#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug  4 15:56:24 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 04 Aug 2010 15:56:24 -0000
Subject: [Varnish] #741: varnish{top,
	stat} crash ("Assert error") when output scrolls past shell window
	height
In-Reply-To: <039.1e2530046b7cabd1272069f8168da7d3@varnish-cache.org>
References: <039.1e2530046b7cabd1272069f8168da7d3@varnish-cache.org>
Message-ID: <048.ef4a7335e439202de84d55f6b8a1178d@varnish-cache.org>

#741: varnish{top,stat} crash ("Assert error") when output scrolls past shell
window height
-------------------------+--------------------------------------------------
 Reporter:  rb           |       Owner:  phk  
     Type:  defect       |      Status:  new  
 Priority:  normal       |   Milestone:       
Component:  varnishstat  |     Version:  trunk
 Severity:  critical     |    Keywords:       
-------------------------+--------------------------------------------------

Comment(by phk):

 This is undocumented behaviour by ncurses.  It is only present in -trunk
 and will be fixed soonish, I just need to investigate how best to do so.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/741#comment:5>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug  4 16:47:59 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 04 Aug 2010 16:47:59 -0000
Subject: [Varnish] #747: 302 is unconditionally cached by default
Message-ID: <044.d91384d0b55dc35041ffec4ba5f4b9a0@varnish-cache.org>

#747: 302 is unconditionally cached by default
----------------------+-----------------------------------------------------
 Reporter:  trombik   |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  2.1.2
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
 rfc2616 states that "A response received with any other status code (e.g.
 status codes 302 and 307) MUST NOT be returned in a reply to a subsequent
 request unless there are cache-control directives or another header(s)
 that explicitly allow it"

 however, bin/varnishd/cache_center.c caches 302 response without such
 headers. an example is:

 {{{
 Connection:Keep-Alive
 Content-Length:17
 Content-Type:text/plain
 Date:Wed, 04 Aug 2010 10:10:08 GMT
 Keep-Alive:timeout=5, max=50
 Location:http://foo.example.org/bar/
 }}}

 the commit log in question simply says "handle 302 for now".

 http://varnish-cache.org/changeset/497

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/747>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug  4 23:45:29 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 04 Aug 2010 23:45:29 -0000
Subject: [Varnish] #735: Support backend control via CLI
In-Reply-To: <040.5238d8dc11accb237444ccdefb404199@varnish-cache.org>
References: <040.5238d8dc11accb237444ccdefb404199@varnish-cache.org>
Message-ID: <049.830b8837ef1f9e013b0a44a310d5988a@varnish-cache.org>

#735: Support backend control via CLI
-------------------------+--------------------------------------------------
 Reporter:  tgr          |        Owner:  phk    
     Type:  enhancement  |       Status:  closed 
 Priority:  normal       |    Milestone:         
Component:  varnishd     |      Version:  trunk  
 Severity:  normal       |   Resolution:  invalid
 Keywords:               |  
-------------------------+--------------------------------------------------

Comment(by tgr):

 You're right. The naming issue is definitely something to ponder on. But
 meanwhile, if anybody needs this feature bad (like us), there's an interim
 patch that just disables backends in all copies of a director. Obviously,
 it's unsupported, etc.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/735#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Aug  5 04:13:17 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 05 Aug 2010 04:13:17 -0000
Subject: [Varnish] #748: sess_timeout incorrectly used for in-flight requests
Message-ID: <041.55fc5bfd6b2333f61d0fbce65a241ee2@varnish-cache.org>

#748: sess_timeout incorrectly used for in-flight requests
-------------------+--------------------------------------------------------
 Reporter:  xb95   |        Type:  defect
   Status:  new    |    Priority:  normal
Milestone:         |   Component:  build 
  Version:  2.1.0  |    Severity:  minor 
 Keywords:         |  
-------------------+--------------------------------------------------------
 sess_timeout, as per the docs:
 "Idle timeout for persistent sessions. If a HTTP request has not been
 received in this many seconds, the session is closed."

 In reality, (as far as I can tell from some strace debugging) this
 variable is used to set the SO_RCVTIMEO on the bereq when Varnish is
 waiting for a response from the backend.  This seems to lead to "backend
 write error: 11" errors when the backend does not respond fast enough,
 causing Varnish to return a 503 "backend unavailable" message.

 Either the documentation is wrong and sess_timeout is intended to be a
 backend response timeout, or we should have some sort of backend response
 timeout variable to tune separately.

 This is as per version 2.1.0, but a look at the changelog doesn't indicate
 any changes that seem to address this.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/748>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Aug  5 08:11:27 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 05 Aug 2010 08:11:27 -0000
Subject: [Varnish] #749: 503 if web server closes connection too soon.
Message-ID: <040.ed5a2b73f2610e003d4db85ddf243c52@varnish-cache.org>

#749: 503 if web server closes connection too soon.
-------------------------+--------------------------------------------------
 Reporter:  Dan          |       Owner:  phk  
     Type:  enhancement  |      Status:  new  
 Priority:  normal       |   Milestone:       
Component:  varnishd     |     Version:  trunk
 Severity:  normal       |    Keywords:       
-------------------------+--------------------------------------------------
 I have a webserver, that will per definition misbehave.
 This is because its running apache2 with mpm-itk, a worker module that
 does setuid per apache fork, based on Host-header.

 This results in one caveat. If you try to access another virtualhost on
 the same TCP connection, mpm-itk will drop its connection after you've
 transmitted the header, since youve changed the host-header.

 Aparantly not a problem for browsers, but as soon as i stick varnishd in
 front of a server with 2 vhosts, i get 503 every time i alternate between
 the vhosts.

 I'd love a config option to enable something that catches this sudden
 disconnect and works around it.

 I can think of 3 ways to work around this:
  1. Open a TCP connection per src-ip/vhost pair
  2. always close TCP-connection after each fetch
  3. automatic retry on fetch error.

 Option 1 is probably most efficient. 2 would be very inefficient and 3, a
 bit more efficient than 2, and sounds really easy to do :)

 The following small patch has solves the problem for me (option 3).
 {{{
 #!c
 --- /home/dan/cache_center.c    2010-07-24 19:58:03.000000000 +0200
 +++ bin/varnishd/cache_center.c 2010-07-24 20:03:30.000000000 +0200
 @@ -439,6 +439,12 @@

         i = FetchHdr(sp);

 +       /* Retry (once) if fetching headers failed */
 +       if (i) {
 +               WSP(sp, SLT_FetchError, "Error while fetching header,
 retrying.");
 +               i = FetchHdr(sp);
 +       }
 +
         /*
          * Save a copy before it might get mangled in VCL.  When it comes
 to
          * dealing with the body, we want to see the unadultered headers.
 }}}

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/749>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Aug  5 08:26:36 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 05 Aug 2010 08:26:36 -0000
Subject: [Varnish] #745: Varnishstat
In-Reply-To: <049.d40e8595f1a7db9d87f52f66f6308e8a@varnish-cache.org>
References: <049.d40e8595f1a7db9d87f52f66f6308e8a@varnish-cache.org>
Message-ID: <058.39de1d7f06385b269d819b5db4e1b39b@varnish-cache.org>

#745: Varnishstat
--------------------------+-------------------------------------------------
 Reporter:  piripirigoso  |       Owner:  phk                
     Type:  defect        |      Status:  new                
 Priority:  high          |   Milestone:  Varnish 2.1 release
Component:  varnishstat   |     Version:  2.1.2              
 Severity:  critical      |    Keywords:  varnishstats       
--------------------------+-------------------------------------------------

Comment(by yves):

 Hi,


 It appears that the Varnish worker process is being restarted thus
 resetting the varnishstat back to zero. In order to locate the cause of
 this, I would kindly ask that you attach any entries in the syslog
 containing panic messages relating to crahses/kills. This will help
 greatly.


 regards,

 Yves

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/745#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Aug  5 14:45:19 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 05 Aug 2010 14:45:19 -0000
Subject: [Varnish] #750: old probes don't get discarded when new config is
	activated
Message-ID: <042.6bb4103874896f4819e1e351cd4f97fe@varnish-cache.org>

#750: old probes don't get discarded when new config is activated
--------------------+-------------------------------------------------------
 Reporter:  perbu   |       Owner:       
     Type:  defect  |      Status:  new  
 Priority:  normal  |   Milestone:       
Component:  build   |     Version:  2.1.2
 Severity:  minor   |    Keywords:       
--------------------+-------------------------------------------------------
 If you define a probe and then load a new VCL with the same health check
 the old one will hang around and clutter "debug.health".

 vcl.discard works around the issue.

 I'm not sure if the probes are actually _run_. That would be a real bug.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/750>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Fri Aug  6 07:30:36 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 06 Aug 2010 07:30:36 -0000
Subject: [Varnish] #733: Content-Length set to 0 when no Content-Length
	headers is set
In-Reply-To: <040.c336ba7b81c8072d1f094b1bacdacd8a@varnish-cache.org>
References: <040.c336ba7b81c8072d1f094b1bacdacd8a@varnish-cache.org>
Message-ID: <049.431995c14eb58b669e7c0872dbb33265@varnish-cache.org>

#733: Content-Length set to 0 when no Content-Length headers is set
----------------------+-----------------------------------------------------
 Reporter:  zab       |       Owner:  phk                
     Type:  defect    |      Status:  new                
 Priority:  high      |   Milestone:  Varnish 2.1 release
Component:  varnishd  |     Version:  2.1.2              
 Severity:  blocker   |    Keywords:                     
----------------------+-----------------------------------------------------

Comment(by zab):

 After days of researchs, this is a real "Varnish" bug.
 Varnish should leave the HTTP response as it is without computing any
 "Content-Length" in this case.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/733#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug  9 05:57:11 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 09 Aug 2010 05:57:11 -0000
Subject: [Varnish] #750: old probes don't get discarded when new config
	is activated
In-Reply-To: <042.6bb4103874896f4819e1e351cd4f97fe@varnish-cache.org>
References: <042.6bb4103874896f4819e1e351cd4f97fe@varnish-cache.org>
Message-ID: <051.38e71eb524b5b5a8b0f19fd0332f1a4b@varnish-cache.org>

#750: old probes don't get discarded when new config is activated
--------------------+-------------------------------------------------------
 Reporter:  perbu   |        Owner:            
     Type:  defect  |       Status:  closed    
 Priority:  normal  |    Milestone:            
Component:  build   |      Version:  2.1.2     
 Severity:  minor   |   Resolution:  worksforme
 Keywords:          |  
--------------------+-------------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => worksforme


Comment:

 The probes of all loaded VCL's are run, and it is not a bug.

 We run them because we want to be able to instantly switch to any loaded
 VCL and we need to know the backend health to do that.

-- 
Ticket URL: <http://varnish-cache.org/ticket/750#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug  9 06:23:13 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 09 Aug 2010 06:23:13 -0000
Subject: [Varnish] #742: vcl.show possible segmentation fault when using
	format-strings
In-Reply-To: <040.0c3f2f22d121290d2bc82781cff7e17e@varnish-cache.org>
References: <040.0c3f2f22d121290d2bc82781cff7e17e@varnish-cache.org>
Message-ID: <049.dcba83093608f0d159188b5c2b2c949b@varnish-cache.org>

#742: vcl.show possible segmentation fault when using format-strings
---------------------+------------------------------------------------------
  Reporter:  nav     |        Type:  defect
    Status:  closed  |    Priority:  normal
 Milestone:          |   Component:  build 
   Version:  trunk   |    Severity:  normal
Resolution:  fixed   |    Keywords:        
---------------------+------------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Fixed in r5073, thanks!

-- 
Ticket URL: <http://varnish-cache.org/ticket/742#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug  9 06:55:59 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 09 Aug 2010 06:55:59 -0000
Subject: [Varnish] #730: varnishd/cache_fetch.c:FetchBody dropping
	Content-Length on HEAD
In-Reply-To: <045.5df7efb5659ea0e86c7a2e1129826a07@varnish-cache.org>
References: <045.5df7efb5659ea0e86c7a2e1129826a07@varnish-cache.org>
Message-ID: <054.c3027336a2ee84d5171399db8871b762@varnish-cache.org>

#730: varnishd/cache_fetch.c:FetchBody dropping Content-Length on HEAD
-----------------------+----------------------------------------------------
  Reporter:  dormando  |        Type:  defect
    Status:  closed    |    Priority:  normal
 Milestone:            |   Component:  build 
   Version:  trunk     |    Severity:  normal
Resolution:  fixed     |    Keywords:        
-----------------------+----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 (In [5074]) Do not suppress the Content-Length:, Age:, Range: and Proxy-
 Auth headers
 from the backend on a pass operation.

 Fixes: #730

-- 
Ticket URL: </ticket/730#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug  9 07:02:40 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 09 Aug 2010 07:02:40 -0000
Subject: [Varnish] #751: Varnish on SSD
Message-ID: <048.f3e00dfc0b1b09ab79e50cc180d4ec9c@varnish-cache.org>

#751: Varnish on SSD
-------------------------------+--------------------------------------------
 Reporter:  anand_happs        |        Type:  enhancement
   Status:  new                |    Priority:  normal     
Milestone:  After Varnish 2.1  |   Component:  build      
  Version:  trunk              |    Severity:  normal     
 Keywords:                     |  
-------------------------------+--------------------------------------------
 I'm contemplating setting up a varnish cache on a system with SSD drives.

 The obvious benefit is that these systems have great READ speeds and I
 expect my hit ratios to be fairly high.

 Let's assume I can put 7 SSDs in to a RAID configuration. (there are some
 cases that will let me pack in much much more)

 Implementation questions:

 Should I use RAID0? (I expect a drive to fail eventually, so this seems
 dangerous.)

 Should I use RAID10? (This halves my disk footprint, which is costly.)

 Should I use RAID5? (SSDs are known to have "bad" write performance and
 write limits, and all the extra parity writes may slow this down
 considerably.)

 Should I just treat each disk as it's own squid datastore? (how well does
 squid handle multiple data stores? and what happens if/when one fails?)

 Should I ignore datastores and just make the SSDs in to large SWAP
 partitions and let the linux VM do it's thing? (seems sloppy)

 Any advice from you using SSDs in production environments would be greatly
 appreciated. (esp if you're using them for HTTP caches)

 Also how difficult it is for a varnish cache to allow users manage data
 life cycle policy from SSD/NAND flash drives (fusion IO's) to disk. Meta
 data controlled by a policy which can be modified by users.

-- 
Ticket URL: <http://varnish-cache.org/ticket/751>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug  9 08:14:20 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 09 Aug 2010 08:14:20 -0000
Subject: [Varnish] #733: Content-Length set to 0 when no Content-Length
	headers is set
In-Reply-To: <040.c336ba7b81c8072d1f094b1bacdacd8a@varnish-cache.org>
References: <040.c336ba7b81c8072d1f094b1bacdacd8a@varnish-cache.org>
Message-ID: <049.e258c646bfc9dd7f3f5ae9ed36d84bf3@varnish-cache.org>

#733: Content-Length set to 0 when no Content-Length headers is set
----------------------+-----------------------------------------------------
 Reporter:  zab       |        Owner:  phk                
     Type:  defect    |       Status:  closed             
 Priority:  high      |    Milestone:  Varnish 2.1 release
Component:  varnishd  |      Version:  2.1.2              
 Severity:  blocker   |   Resolution:  fixed              
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 (In [5075]) If we get a HTTP/1.1 response with no indicatation of length,
 assume EOF
 encoding, rather than zero length.

 This has implications for a number of testcases which were written
 using the previous assumption.

 Fixes: #733

-- 
Ticket URL: </ticket/733#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug  9 08:15:22 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 09 Aug 2010 08:15:22 -0000
Subject: [Varnish] #751: Varnish on SSD
In-Reply-To: <048.f3e00dfc0b1b09ab79e50cc180d4ec9c@varnish-cache.org>
References: <048.f3e00dfc0b1b09ab79e50cc180d4ec9c@varnish-cache.org>
Message-ID: <057.55845e8f75191661de32c3743cd131dd@varnish-cache.org>

#751: Varnish on SSD
--------------------------------+-------------------------------------------
  Reporter:  anand_happs        |        Type:  enhancement
    Status:  closed             |    Priority:  normal     
 Milestone:  After Varnish 2.1  |   Component:  build      
   Version:  trunk              |    Severity:  normal     
Resolution:  invalid            |    Keywords:             
--------------------------------+-------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => invalid


Comment:

 Sorry, this kind of question should be directed to the varnish-misc
 mailing list, it does not belong in our bug-tracking database.

-- 
Ticket URL: <http://varnish-cache.org/ticket/751#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug  9 08:35:07 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 09 Aug 2010 08:35:07 -0000
Subject: [Varnish] #747: 302 is unconditionally cached by default
In-Reply-To: <044.d91384d0b55dc35041ffec4ba5f4b9a0@varnish-cache.org>
References: <044.d91384d0b55dc35041ffec4ba5f4b9a0@varnish-cache.org>
Message-ID: <053.f63db87d607b2c9a0afadadb55360a2f@varnish-cache.org>

#747: 302 is unconditionally cached by default
----------------------+-----------------------------------------------------
 Reporter:  trombik   |        Owner:  phk       
     Type:  defect    |       Status:  closed    
 Priority:  normal    |    Milestone:            
Component:  varnishd  |      Version:  2.1.2     
 Severity:  normal    |   Resolution:  worksforme
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => worksforme


Comment:

 You run into an interesting detail here.

 Varnish is not a cache/proxy in the RFC2616 sense of those words, it is a
 webserver.

 If you read RFC2616 very carefully, you will find one or two places that
 refer to caches on the server side which they forgot to remove.

 The drafts had text about server side caches, but it was removed for being
 pointless.

 If the cache is under the same administrative control as the webserver, it
 becomes the webserver.

 if it is not under the same administrative control as the webserver, it is
 by definition a client side cache, as covered by RFC2616.

 So the text you point to is not controlling for Varnish.

 As a result we need to make an independent decision: cache 302 or not ?

 We have made the decision that we cache those with the default_ttl, on the
 belief that people deploy Varnish to defend the backend from traffic, and
 we should do that as best we can.

 In that context a 302 is just as much 'traffic' as 200.

 If you don't want your 302's cached, you can set the default_ttl to zero
 or just do it for 302's in VCL.

-- 
Ticket URL: <http://varnish-cache.org/ticket/747#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug  9 08:52:23 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 09 Aug 2010 08:52:23 -0000
Subject: [Varnish] #744: CLI repeats previous commands instead of
	executing the current one
In-Reply-To: <040.7bcbd34eff3803a79d8b768f5b7f9087@varnish-cache.org>
References: <040.7bcbd34eff3803a79d8b768f5b7f9087@varnish-cache.org>
Message-ID: <049.c804d09e82b5943a770831bd54473fb8@varnish-cache.org>

#744: CLI repeats previous commands instead of executing the current one
----------------------+-----------------------------------------------------
 Reporter:  tgr       |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  2.1.2
 Severity:  major     |    Keywords:  cli  
----------------------+-----------------------------------------------------

Comment(by phk):

 I have not been able to reproduce this yet.

 Does it depend on the size of the output from the CLI commands ?

 Ie: can you reproduce it using only the "banner" CLI command ?

 Can you reproduce it on -trunk ?

-- 
Ticket URL: <http://varnish-cache.org/ticket/744#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug  9 11:19:10 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 09 Aug 2010 11:19:10 -0000
Subject: [Varnish] #748: sess_timeout incorrectly used for in-flight
	requests
In-Reply-To: <041.55fc5bfd6b2333f61d0fbce65a241ee2@varnish-cache.org>
References: <041.55fc5bfd6b2333f61d0fbce65a241ee2@varnish-cache.org>
Message-ID: <050.f88be80e8436701ae85157dd75959e20@varnish-cache.org>

#748: sess_timeout incorrectly used for in-flight requests
--------------------+-------------------------------------------------------
 Reporter:  xb95    |       Owner:  martin
     Type:  defect  |      Status:  new   
 Priority:  normal  |   Milestone:        
Component:  build   |     Version:  2.1.0 
 Severity:  minor   |    Keywords:        
--------------------+-------------------------------------------------------
Changes (by tfheen):

  * owner:  => martin


-- 
Ticket URL: <http://varnish-cache.org/ticket/748#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug  9 11:29:38 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 09 Aug 2010 11:29:38 -0000
Subject: [Varnish] #746: Varnish keep crashing since i use pipe
In-Reply-To: <044.aca684cffee52eac0f54f3107612f40f@varnish-cache.org>
References: <044.aca684cffee52eac0f54f3107612f40f@varnish-cache.org>
Message-ID: <053.d208da1725ac4bf955e8b6724f8bfbca@varnish-cache.org>

#746: Varnish keep crashing since i use pipe
----------------------+-----------------------------------------------------
 Reporter:  ccastro   |       Owner:  phk        
     Type:  defect    |      Status:  new        
 Priority:  high      |   Milestone:             
Component:  varnishd  |     Version:  trunk      
 Severity:  normal    |    Keywords:  pipe, 2.1.3
----------------------+-----------------------------------------------------
Changes (by tfheen):

  * owner:  martin => phk


-- 
Ticket URL: <http://varnish-cache.org/ticket/746#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug  9 11:38:23 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 09 Aug 2010 11:38:23 -0000
Subject: [Varnish] #721: hash and client director docs.
In-Reply-To: <042.44046c3f38fda5026350770b01e061ae@varnish-cache.org>
References: <042.44046c3f38fda5026350770b01e061ae@varnish-cache.org>
Message-ID: <051.73a6568f6cc64ee9102c4f79f6e594af@varnish-cache.org>

#721: hash and client director docs.
---------------------------+------------------------------------------------
 Reporter:  perbu          |       Owner:       
     Type:  documentation  |      Status:  new  
 Priority:  normal         |   Milestone:       
Component:  build          |     Version:  trunk
 Severity:  normal         |    Keywords:  perbu
---------------------------+------------------------------------------------

Comment(by phk):

 I need to add the client.ident VCL variable so that the "client" director
 can be told to look at cookies or X-F-F header etc.

-- 
Ticket URL: <http://varnish-cache.org/ticket/721#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug  9 11:41:52 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 09 Aug 2010 11:41:52 -0000
Subject: [Varnish] #750: old probes don't get discarded when new config
	is activated
In-Reply-To: <042.6bb4103874896f4819e1e351cd4f97fe@varnish-cache.org>
References: <042.6bb4103874896f4819e1e351cd4f97fe@varnish-cache.org>
Message-ID: <051.bb2d0a96a37951179ccc03697f2b39f4@varnish-cache.org>

#750: old probes don't get discarded when new config is activated
--------------------+-------------------------------------------------------
 Reporter:  perbu   |        Owner:            
     Type:  defect  |       Status:  closed    
 Priority:  normal  |    Milestone:            
Component:  build   |      Version:  2.1.2     
 Severity:  minor   |   Resolution:  worksforme
 Keywords:          |  
--------------------+-------------------------------------------------------

Comment(by perbu):

 This will be a problem for those who do a lot of vcl changes. Having 20
 configs hammer at your server once a second (not unlikely) will tax your
 server heavily.

 Proposed architectural changes:

 - VCL autodiscard.
 - coalescing of health checks.
 - use initial state when switching config.

 I propose we use the last one - since it adheres to the principle of least
 surprise, at least for me.


 Per.

-- 
Ticket URL: <http://varnish-cache.org/ticket/750#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug  9 11:52:17 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 09 Aug 2010 11:52:17 -0000
Subject: [Varnish] #750: old probes don't get discarded when new config
	is activated
In-Reply-To: <042.6bb4103874896f4819e1e351cd4f97fe@varnish-cache.org>
References: <042.6bb4103874896f4819e1e351cd4f97fe@varnish-cache.org>
Message-ID: <051.20a8caec5702e34d5a910045452044b6@varnish-cache.org>

#750: old probes don't get discarded when new config is activated
--------------------+-------------------------------------------------------
 Reporter:  perbu   |        Owner:            
     Type:  defect  |       Status:  closed    
 Priority:  normal  |    Milestone:            
Component:  build   |      Version:  2.1.2     
 Severity:  minor   |   Resolution:  worksforme
 Keywords:          |  
--------------------+-------------------------------------------------------

Comment(by phk):

 This is why we have the secret/magic layer of backends shared between
 VCL's that define them identically.

 Unless you fiddle your backend-defs, all your VCL's should share the same
 poll-instance.

-- 
Ticket URL: <http://varnish-cache.org/ticket/750#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug  9 11:55:41 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 09 Aug 2010 11:55:41 -0000
Subject: [Varnish] #744: CLI repeats previous commands instead of
	executing the current one
In-Reply-To: <040.7bcbd34eff3803a79d8b768f5b7f9087@varnish-cache.org>
References: <040.7bcbd34eff3803a79d8b768f5b7f9087@varnish-cache.org>
Message-ID: <049.be227d0357a9fa6532202a7117a2a1ea@varnish-cache.org>

#744: CLI repeats previous commands instead of executing the current one
----------------------+-----------------------------------------------------
 Reporter:  tgr       |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  2.1.2
 Severity:  major     |    Keywords:  cli  
----------------------+-----------------------------------------------------

Comment(by tgr):

 It seems "banner" is not affected and doesn't affect anything itself - I
 can use it several times and I always get proper output (i.e. the banner).
 When I try another command after "banner", the last command given before
 "banner" is repeated. Only commands that go to the child are affected.

 I don't think it depends on the size. Commands with short output get
 repeated too.

-- 
Ticket URL: <http://varnish-cache.org/ticket/744#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From perbu at varnish-software.com  Mon Aug  9 12:05:57 2010
From: perbu at varnish-software.com (Per Buer)
Date: Mon, 09 Aug 2010 12:05:57 -0000
Subject: [Varnish] #750: old probes don't get discarded when new config is
	activated
In-Reply-To: <051.20a8caec5702e34d5a910045452044b6@varnish-cache.org>
References: <042.6bb4103874896f4819e1e351cd4f97fe@varnish-cache.org>
	<051.20a8caec5702e34d5a910045452044b6@varnish-cache.org>
Message-ID: <AANLkTikw4QCW2modGkWNzrAbxumqDX=KGckw9SFin+oB@mail.gmail.com>

Impressive, Poul. You thought of everything. :-)



-- 
Per Buer,  Varnish Software
Phone: +47 21 98 92 61 / Mobile: +47 958 39 117 / skype: per.buer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-bugs/attachments/20100809/dc1c8bf5/attachment.html>

From varnish-bugs at varnish-cache.org  Mon Aug  9 12:07:00 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 09 Aug 2010 12:07:00 -0000
Subject: [Varnish] #750: old probes don't get discarded when new config
	is activated
In-Reply-To: <042.6bb4103874896f4819e1e351cd4f97fe@varnish-cache.org>
References: <042.6bb4103874896f4819e1e351cd4f97fe@varnish-cache.org>
Message-ID: <051.be3bbe14a50b6c48bdc1ecf530361b22@varnish-cache.org>

#750: old probes don't get discarded when new config is activated
--------------------+-------------------------------------------------------
 Reporter:  perbu   |        Owner:            
     Type:  defect  |       Status:  closed    
 Priority:  normal  |    Milestone:            
Component:  build   |      Version:  2.1.2     
 Severity:  minor   |   Resolution:  worksforme
 Keywords:          |  
--------------------+-------------------------------------------------------

Comment(by perbu):

 Impressive. You've thought of everything. :-)


 Per.

-- 
Ticket URL: <http://varnish-cache.org/ticket/750#comment:4>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug  9 21:46:46 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 09 Aug 2010 21:46:46 -0000
Subject: [Varnish] #748: sess_timeout incorrectly used for in-flight
	requests
In-Reply-To: <041.55fc5bfd6b2333f61d0fbce65a241ee2@varnish-cache.org>
References: <041.55fc5bfd6b2333f61d0fbce65a241ee2@varnish-cache.org>
Message-ID: <050.1c939c1842926401fff42ac19b5bbe70@varnish-cache.org>

#748: sess_timeout incorrectly used for in-flight requests
--------------------+-------------------------------------------------------
 Reporter:  xb95    |       Owner:  martin
     Type:  defect  |      Status:  new   
 Priority:  normal  |   Milestone:        
Component:  build   |     Version:  2.1.0 
 Severity:  minor   |    Keywords:        
--------------------+-------------------------------------------------------

Comment(by tsuna):

 To be more precise, the bug is in source:trunk/varnish-
 cache/bin/varnishd/cache_acceptor.c#4989 in vca_acct() around line 249
 where the value that's passed to {{{setsockopt()}}} to set the
 {{{SO_RCVTIMEO}}} is initialized incorrectly from
 {{{params->sess_timeout}}}.

 {{{params->sess_timeout}}} is used correctly in the waiter code, e.g. in
 source:trunk/varnish-cache/bin/varnishd/cache_waiter_epoll.c#4989 in
 {{{vca_main()}}} around line 192.  It seems to me that someone added a
 timeout in {{{cache_acceptor.c}}} after {{{params->sess_timeout}}} was
 introduced, and the misleading name {{{sess_timeout}}} lead them to
 believe that this was the appropriate timeout to use.  This variable
 should really be renamed {{{idle_timeout}}} or something less confusing
 like that.

 The consequence of this bug, just to make it clearer to the readers not
 too familiar with Varnish, is that a default Varnish config will not wait
 more than 5 seconds for a request to complete.  5 seconds is a hell of a
 lot of time, which is why many people probably didn't notice, but it can
 happen.  Until this is fixed, the workaround is to up {{{sess_timeout}}}
 to whatever request timeout you think is reasonable (by passing {{{-p
 sess_timeout 25s}}} in argument to {{{varnishd}}} ? if you want a 25s
 timeout for example).

-- 
Ticket URL: <http://varnish-cache.org/ticket/748#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Aug 10 09:09:20 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 10 Aug 2010 09:09:20 -0000
Subject: [Varnish] #721: hash and client director docs.
In-Reply-To: <042.44046c3f38fda5026350770b01e061ae@varnish-cache.org>
References: <042.44046c3f38fda5026350770b01e061ae@varnish-cache.org>
Message-ID: <051.5126a6413bd1c6911a051514a5af0ccd@varnish-cache.org>

#721: hash and client director docs.
---------------------------+------------------------------------------------
 Reporter:  perbu          |       Owner:       
     Type:  documentation  |      Status:  new  
 Priority:  normal         |   Milestone:       
Component:  build          |     Version:  trunk
 Severity:  normal         |    Keywords:  perbu
---------------------------+------------------------------------------------

Comment(by phk):

 Done, it ended up being "client.identity" for consistency with
 "server.identity".

 See r5080 and v00028.vtc

-- 
Ticket URL: <http://varnish-cache.org/ticket/721#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Aug 10 09:40:25 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 10 Aug 2010 09:40:25 -0000
Subject: [Varnish] #746: Varnish keep crashing since i use pipe
In-Reply-To: <044.aca684cffee52eac0f54f3107612f40f@varnish-cache.org>
References: <044.aca684cffee52eac0f54f3107612f40f@varnish-cache.org>
Message-ID: <053.01e4080d4fe53edef3aaf9570259e059@varnish-cache.org>

#746: Varnish keep crashing since i use pipe
-------------------------+--------------------------------------------------
 Reporter:  ccastro      |        Owner:  phk   
     Type:  defect       |       Status:  closed
 Priority:  high         |    Milestone:        
Component:  varnishd     |      Version:  trunk 
 Severity:  normal       |   Resolution:  fixed 
 Keywords:  pipe, 2.1.3  |  
-------------------------+--------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 (In [5082]) Fix a corner-case of pipe mode close-down processing, by
 simplifying
 the logic and letting vca_close_session() and VBE_CloseFd() carry out
 the last rites.

 Closes: #746

-- 
Ticket URL: </ticket/746#comment:4>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug 11 09:08:30 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 11 Aug 2010 09:08:30 -0000
Subject: [Varnish] #545: synthetic screws national characters
In-Reply-To: <041.ca57a3dedbc1a621c14a034da6d01e9d@varnish-cache.org>
References: <041.ca57a3dedbc1a621c14a034da6d01e9d@varnish-cache.org>
Message-ID: <050.c256b531caa621882199b2fd3554059c@varnish-cache.org>

#545: synthetic screws national characters
----------------------+-----------------------------------------------------
 Reporter:  kolo      |        Owner:  phk    
     Type:  defect    |       Status:  closed 
 Priority:  normal    |    Milestone:         
Component:  varnishd  |      Version:  2.0    
 Severity:  normal    |   Resolution:  invalid
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by kristian):

  * status:  new => closed
  * resolution:  => invalid


Comment:

 I'm moving this to the FAQ and shopping list, as it's turned into a
 feature request and we keep those on the shopping list.

 It's definitely something we are interested in fixing though. I heard some
 mumbling about looking into it in conjunction to the synthetic stuff being
 re-worked.

-- 
Ticket URL: <http://varnish-cache.org/ticket/545#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Aug 12 09:23:14 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 12 Aug 2010 09:23:14 -0000
Subject: [Varnish] #749: 503 if web server closes connection too soon.
In-Reply-To: <040.ed5a2b73f2610e003d4db85ddf243c52@varnish-cache.org>
References: <040.ed5a2b73f2610e003d4db85ddf243c52@varnish-cache.org>
Message-ID: <049.1502edba630685d21fcf5ea03a558730@varnish-cache.org>

#749: 503 if web server closes connection too soon.
-------------------------+--------------------------------------------------
 Reporter:  Dan          |       Owner:  phk  
     Type:  enhancement  |      Status:  new  
 Priority:  normal       |   Milestone:       
Component:  varnishd     |     Version:  trunk
 Severity:  normal       |    Keywords:       
-------------------------+--------------------------------------------------

Comment(by phk):

 There will always be a race, where the backend closes after we sent the
 request, and the more distant the backend, the more likely the race.

 Retrying is the sensible thing to do, but I am not convinced that it is
 always the sensible thing to do.

 For one thing, we should only retry if we got a recycled backend
 connection.

 But once we retry, we may get another recycled backend connection, so how
 many times do we retry ?

 Input welcome...

-- 
Ticket URL: <http://varnish-cache.org/ticket/749#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Aug 12 09:43:10 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 12 Aug 2010 09:43:10 -0000
Subject: [Varnish] #741: varnish{top,
	stat} crash ("Assert error") when output scrolls past shell window
	height
In-Reply-To: <039.1e2530046b7cabd1272069f8168da7d3@varnish-cache.org>
References: <039.1e2530046b7cabd1272069f8168da7d3@varnish-cache.org>
Message-ID: <048.942f245337ba07e7a8054c82bf3f06be@varnish-cache.org>

#741: varnish{top,stat} crash ("Assert error") when output scrolls past shell
window height
-------------------------+--------------------------------------------------
 Reporter:  rb           |       Owner:  phk  
     Type:  defect       |      Status:  new  
 Priority:  normal       |   Milestone:       
Component:  varnishstat  |     Version:  trunk
 Severity:  critical     |    Keywords:       
-------------------------+--------------------------------------------------

Comment(by phk):

 Ok, not quite undocumented: semi-documented.

 The move() function returns error if the position is outside the window,
 and some, probably all, mv* prefixed functions inherit this behaviour, but
 does not say so in their manual pages.

 I have sent an error report to bugs-ncurses.

-- 
Ticket URL: <http://varnish-cache.org/ticket/741#comment:6>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Aug 12 09:48:50 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 12 Aug 2010 09:48:50 -0000
Subject: [Varnish] #741: varnish{top,
	stat} crash ("Assert error") when output scrolls past shell window
	height
In-Reply-To: <039.1e2530046b7cabd1272069f8168da7d3@varnish-cache.org>
References: <039.1e2530046b7cabd1272069f8168da7d3@varnish-cache.org>
Message-ID: <048.56e7221c6eab7d8c1f2278b896df6cde@varnish-cache.org>

#741: varnish{top,stat} crash ("Assert error") when output scrolls past shell
window height
-------------------------+--------------------------------------------------
 Reporter:  rb           |        Owner:  phk   
     Type:  defect       |       Status:  closed
 Priority:  normal       |    Milestone:        
Component:  varnishstat  |      Version:  trunk 
 Severity:  critical     |   Resolution:  fixed 
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 (In [5100]) Don't assert good returns from ncurses for now.

 Fixes: #741

-- 
Ticket URL: </ticket/741#comment:7>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Aug 12 12:35:18 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 12 Aug 2010 12:35:18 -0000
Subject: [Varnish] #749: 503 if web server closes connection too soon.
In-Reply-To: <040.ed5a2b73f2610e003d4db85ddf243c52@varnish-cache.org>
References: <040.ed5a2b73f2610e003d4db85ddf243c52@varnish-cache.org>
Message-ID: <049.e8c8d896f3e982550620717d0133291e@varnish-cache.org>

#749: 503 if web server closes connection too soon.
-------------------------+--------------------------------------------------
 Reporter:  Dan          |       Owner:  phk  
     Type:  enhancement  |      Status:  new  
 Priority:  normal       |   Milestone:       
Component:  varnishd     |     Version:  trunk
 Severity:  normal       |    Keywords:       
-------------------------+--------------------------------------------------

Comment(by Dan):

 Replying to [comment:1 phk]:

 > For one thing, we should only retry if we got a recycled backend
 connection.
 > But once we retry, we may get another recycled backend connection,
 How about forcing a new connection on-retry (hence not recycling) to avoid
 retrying a lot of dead connections in case the webserver had a general
 problem?

 > so how many times do we retry ?

 Make it configurable and default to 1 or 2 retries.

 Another thing is whether there should be a small sleep before retry, and
 if there should be "incremental backoff" on failed retries ? So each retry
 attempt sleeps a couple of miliseconds * retry-attempt-count.

 Eg. "10ms * (retry_count-1)":
  * 1st retry: 0*10 = sleep 0ms
  * 2nd retry: 1*10 = sleep 10ms
  * 3nd retry: 2*10 = sleep 20ms

 Dont know if thats a good idea, but im thinking it will give whatever
 problem occured a little time to solve itself.

-- 
Ticket URL: <http://varnish-cache.org/ticket/749#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Fri Aug 13 08:54:33 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 13 Aug 2010 08:54:33 -0000
Subject: [Varnish] #752: [Bug] [varnish-2.1.2] No Null pointer check
	[strdup] :: no assertion
Message-ID: <046.aecab54628e14837d4b17fc39db52bf1@varnish-cache.org>

#752: [Bug] [varnish-2.1.2] No Null pointer check [strdup] :: no assertion
-----------------------+----------------------------------------------------
 Reporter:  pprocacci  |       Owner:  phk                
     Type:  defect     |      Status:  new                
 Priority:  low        |   Milestone:  Varnish 2.1 release
Component:  varnishd   |     Version:  2.1.2              
 Severity:  minor      |    Keywords:  Null Pointer       
-----------------------+----------------------------------------------------
 vcc_compile.c: line 370 of 682

 <snip>
         sp->name = strdup(name);
 </snip>

 strdup could return NULL, but sp->name is never checked.  There is no
 assertion here which I gather should be.

-- 
Ticket URL: <http://varnish-cache.org/ticket/752>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Fri Aug 13 10:14:08 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 13 Aug 2010 10:14:08 -0000
Subject: [Varnish] #749: 503 if web server closes connection too soon.
In-Reply-To: <040.ed5a2b73f2610e003d4db85ddf243c52@varnish-cache.org>
References: <040.ed5a2b73f2610e003d4db85ddf243c52@varnish-cache.org>
Message-ID: <049.441289437cea92df39f81256084366fc@varnish-cache.org>

#749: 503 if web server closes connection too soon.
-------------------------+--------------------------------------------------
 Reporter:  Dan          |        Owner:  phk   
     Type:  enhancement  |       Status:  closed
 Priority:  normal       |    Milestone:        
Component:  varnishd     |      Version:  trunk 
 Severity:  normal       |   Resolution:  fixed 
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 (In [5102]) Retry backend fetches one time if we got a recycled conncetion
 and
 the transfer failed before we received anything.

 Fixes: #749

-- 
Ticket URL: </ticket/749#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Fri Aug 13 10:18:15 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 13 Aug 2010 10:18:15 -0000
Subject: [Varnish] #749: 503 if web server closes connection too soon.
In-Reply-To: <040.ed5a2b73f2610e003d4db85ddf243c52@varnish-cache.org>
References: <040.ed5a2b73f2610e003d4db85ddf243c52@varnish-cache.org>
Message-ID: <049.c45473e03ec2972af511fa24b45011ff@varnish-cache.org>

#749: 503 if web server closes connection too soon.
-------------------------+--------------------------------------------------
 Reporter:  Dan          |        Owner:  phk   
     Type:  enhancement  |       Status:  closed
 Priority:  normal       |    Milestone:        
Component:  varnishd     |      Version:  trunk 
 Severity:  normal       |   Resolution:  fixed 
 Keywords:               |  
-------------------------+--------------------------------------------------

Comment(by phk):

 I have added code that does one retry in carefully limited circumstances
 (see above)

 You ideas about incremental backoff are relevant, but conflict with our
 policy of trying to protect the backend, rather than attack it, the
 assumption being that if it is flakey now, hitting it harder is not likely
 to make it any better.

 If you want to force retries, VCL has the return(restart) facility that
 will allow you to do that.

-- 
Ticket URL: <http://varnish-cache.org/ticket/749#comment:4>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Fri Aug 13 10:19:44 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 13 Aug 2010 10:19:44 -0000
Subject: [Varnish] #752: [Bug] [varnish-2.1.2] No Null pointer check
	[strdup] :: no assertion
In-Reply-To: <046.aecab54628e14837d4b17fc39db52bf1@varnish-cache.org>
References: <046.aecab54628e14837d4b17fc39db52bf1@varnish-cache.org>
Message-ID: <055.89f018116c498c93dbc1ad6208d2db88@varnish-cache.org>

#752: [Bug] [varnish-2.1.2] No Null pointer check [strdup] :: no assertion
--------------------------+-------------------------------------------------
 Reporter:  pprocacci     |        Owner:  phk                
     Type:  defect        |       Status:  closed             
 Priority:  low           |    Milestone:  Varnish 2.1 release
Component:  varnishd      |      Version:  2.1.2              
 Severity:  minor         |   Resolution:  fixed              
 Keywords:  Null Pointer  |  
--------------------------+-------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 (In [5103]) Add a missing assert.

 Spotted by: pprocacci  (Thanks!)

 Fixes: #752

-- 
Ticket URL: </ticket/752#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Fri Aug 13 19:01:03 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 13 Aug 2010 19:01:03 -0000
Subject: [Varnish] #753: Varnish craches
Message-ID: <049.e4871ddd65d5d7434dab456a42301aa3@varnish-cache.org>

#753: Varnish craches
--------------------------+-------------------------------------------------
 Reporter:  piripirigoso  |       Owner:  phk                
     Type:  defect        |      Status:  new                
 Priority:  highest       |   Milestone:  Varnish 2.1 release
Component:  varnishd      |     Version:  2.1.2              
 Severity:  major         |    Keywords:  Panic message      
--------------------------+-------------------------------------------------
 My installation's Varnish, has shown the following error:

 Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25313) died signal=6
 Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25313) Panic message:
 Assert error in WS_Release(), cache_ws.c line 193: Condition(bytes <=
 ws->e - ws->f) not true. thread = (cache-worker) ident =
 Linux,2.6.18-164.el5,x86_64,-sfile,-hcritbit,epoll Backtrace: 0x422616:
 /usr/sbin/varnishd [0x422616] 0x42d475:
 /usr/sbin/varnishd(WS_Release+0xf5) [0x42d475] 0x427b33:
 /usr/sbin/varnishd [0x427b33] 0x42bc45:
 /usr/sbin/varnishd(VRT_SetHdr+0xf5) [0x42bc45] 0x2ab1ab103b22:
 ./vcl.1P9zoqAU.so [0x2ab1ab103b22] 0x427693:
 /usr/sbin/varnishd(VCL_recv_method+0x43) [0x427693] 0x414097:
 /usr/sbin/varnishd(CNT_Session+0x5b7) [0x414097] 0x424a68:
 /usr/sbin/varnishd [0x424a68] 0x423d4d: /usr/sbin/varnishd [0x423d4d]
 0x3028c064a7: /lib64/libpthread.so.0 [0x3028c064a7] sp = 0x2ab1f0b68008 {
 fd = 3143, id = 3143, xid = 1038927643, client = 187.78.137.224:3585, step
 = STP_RECV, handling = deliver, restarts = 0, esis = 0 ws = 0x2ab1f0b68078
 { id = "sess", {s,f,r,e} = {0x2ab1f0b68c90,+63992,+65536,+65536}, },
 http[req] = { ws = 0x2ab1f0b68078[sess] "GET",
 "/images/shopping/vitrine3.png", "HTTP/1.1", "Accept: */*", "Referer:
 http://clickjogos.uol.com.br/Jogos-online/Acao-e-Aventura/N/", "Accept-
 Language: pt-br", "User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows
 NT 5.1; Trident/4.0; InfoPath.2)", "If-Modified-Since: Tue, 27 Jul 2010
 08:11:30 GMT", "Host: img3.clickjogos.uol.com.br", "Connection: Keep-
 Alive", "Accept-Encoding: gzip", "cookie:
 __utma=123316185.1934051457.1264250584.1280786857.1280789299.119;
 __utmz=123316185.1280787361.118.46.utmccn=(organic)|utmcsr=google|utmctr=batalha+site:clickjogos.uol.com.br|utmcmd=organic;
 RTRK.17=V1|1267445998450#6093e2f62552447c326e197e892b81417681ec3cd68189150f4c3c17479ee12585c2e39957281acde264efd989dd221953b764adc1720f0f8a99f90a0ffe628d3bac91a0173a4eb127fe63c358318b601c737adf1f0e881c6c749a03242176de638242c30e402136742b12b1aa471ffbf9cb3345c3c523840d7b4dad75948ea89dd689c11f169262fa50c5ac918e8d70c941fa0b34da53bc45696bf8759c310a8ef70a970ab1842d79dfa5360f8e72ea295b69197dfac07565c881544cc3c852d866cb5be3eb55fd91c96e37f9ab1e7dfc739d1c57542d5c9af278751bf3266cf58d04a43724028b5cf9d0560c0917005b3eccdfca9b31b38bf4c95a8cff262bf51a7497248882e8a485f9b8308395dcd1711e4e369cc2f66c218be448984d53;
 __gads=ID=f4b750b8c438c809:T=1262973373:S=ALNI_MYWYZTAE3jUHAI_Z4WCwBZ5T55zlg;
 ReachVita=0;
 RTRK.1=V1|1266418080111#ae0fa7ec6a4a1a1245c5a3dfc0c724e932a67502b32b66f406d270d8c54af4de22338f9923fe8924b986a9bb378a71a0522aecee1dcd1ffe8f40911aced5088837f2db46cca0321cf8c7fb62ed6cf68769b4a45be078301ec063e2f16efcced3c820a178f5a0f1f65b7f3eca97cbae2470a73825d03badcffe01cdcbd2577b1e5a9363c90324770b8043379c32e0c98b163afb0e93f19c56e2b69227ff949d58d19abc6cbce7b582592207ac1810e6a05a4f650522debee9392af7c31c715574;
 RTRK.11=V1|1266448187184#4d9a70ba92038ed4e090fc3904c454b81097d72c105f0a462cb9e2f73a74723beee4bdd4673d32224cbdaeff701da72b6c7bf603706ed1afde74c279a60eefae27c35509b4ca38704c2afefd12bf28dd2abc5899d3e60e094af9ce487b4af67fcab15518bdd0a8b11f00e7c7085f0a247d4d110bade850e05d6289dbcbe79006b59c934910a49de9120e3f76074159a5b12c9e8c260c64bba164669c2d7c96a79c66580fdef279005ec94f63b8f6aea8c5276c2094d124f4fb0ba4cfcd2446ce;
 RTRK.9=V1|1270922796677#af8668dddb8becb4b5caec582ed4e98e7e670a8091365f801c8ca4f79a16733d13c71001ab2ef7bc024ce006bc1174537fc978fb549c4fdb4ec126c80cc366f03443d90a99d035834842103b2d6ef369daaefed02c3bfb338b5a958c1d4ab81be0784d90c0fcf334a5981fc3202ad77e024cbe87ca719b0dc74c5f12243945a1bccee35f03f57e09fad3ae6a001a8fee6a0d814222ef89f89d4ce26c5bb937633e5e536c59379d1f526abf657517b113;
 uol_ut=187.78.1.149.1277569632060504; jogo_unique_user=1;
 RTRK.21=V1|1279490890283#bc24092a770d08eca70b9b1d80a1f6291097d72c105f0a462cb9e2f73a74723b213a8e283e624a65186a2d9ff1ef3fe81a65370d748419cf3579ce39be9310256b8d640f9cb9b0e72b6a2448e9c75879ddc288b08f8b31ada81becc286db2096957a4cf54a6241fdc46ce3ed50608af7c582b0fb73ecb75ae98b38294908e6670af7ccdaed3a3219019c99fcbd657b8b92c55bab47275ed1598e7908ac6446bc1dfa0dbfefb2c740b1c41b2b34b6697533b118d52bf757c3e24740ae73ce592b;
 RTRK.76=V1|1279542784635#6c938b0eee9eda23be11213ae0875fcc5d2fecf08491ca20d31fed160fb1faae9378b335f3eb2111c4eac5a5b63baa3ca2f6e012c2e8cc0b1626d3d07205ff7b08ff73021abc6b5a4600a6554ded25c244ce972f79c67e5e1b3d2568e34904406e36c42d1abf042b6740347e29c4e5ba;
 RTRK.12=V1|1280318741777#655a54020017f0210051bcdca62a80d07e670a8091365f801c8ca4f79a16733d92f559707ef8af746433345acc1c3cc69df958992f64587cfa30ce65414d0d2592ea3ffebed05d582dde09ff95f94ceb7cad96029c28e53fc363a28e496a669abaf6318f1fe193d11dfdb8ad3a3905f9b09540cdfe75145dacaf3c94b2c192ea5fcbe1d034b370743f468fc727666929dcc31f2e55ce1b52531aba83739985ad8d23f6188f53059234921bfcf164a8ef147be6e65fc79897d0f4d24d5fb3a4e8fbba015ae337ed8525095a6370eabf61fc6a99440a8a2a0b84632f30f536dce6b11d240a82c41c58443316d71cb59dca0b3a5cee2419c30572957e1437cd1a6f;
 AdUol=n+site:clickjogos.uol.com.br\www.google.com|SOCCER+STARS+site:clickjogos.uol.com.br\www.google.com|soccer%2520stars%2520no%2520click%2520jogos\www.google.com|soccer+star+site:clickjogos.uol.com.br\www.google.com|futebol+de+poderes+site:clickjogos.uol.com.br\www.google.com|;
 quietAlarms=1; 2t5i_unique_user=1", }, worker = 0x2ab2b9d02e60 { ws =
 0x2ab2b9d02fc8 { id = "wrk", {s,f,r,e} =
 {0x2ab2b9cf0e10,0x2ab2b9cf0e10,(nil),+65536}, }, }, vcl = { srcname = {
 "input", "Default", "/etc/varnish/uolproxy_backend.vcl",
 "/etc/varnish/backend/virgula.vcl", "/etc/varnish/backend/videolog.vcl",
 "/etc/varnish/backend/hardgamer.vcl",
 "/etc/varnish/backend/trofeuinternet.vcl",
 "/etc/varnish/backend/cosmopax.vcl",
 "/etc/varnish/backend/clickjogos.vcl", }, }, },
 Aug 3 22:12:46 a2-mulher2 varnishd[13511]: child (25854) Started
 Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25854) said
 Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25854) said Child starts
 Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25854) said managed to
 mmap 30064771072 bytes of 3006477107

 Its happen once a two minutes.

 Any Ideia?

-- 
Ticket URL: <http://varnish-cache.org/ticket/753>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 16 05:44:55 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 16 Aug 2010 05:44:55 -0000
Subject: [Varnish] #754: CLI communication error after some time running
Message-ID: <044.547964d2ae8acba825f355bf9b0bb5fd@varnish-cache.org>

#754: CLI communication error after some time running
---------------------+------------------------------------------------------
 Reporter:  Estartu  |        Type:  defect
   Status:  new      |    Priority:  normal
Milestone:           |   Component:  build 
  Version:  trunk    |    Severity:  normal
 Keywords:  cli      |  
---------------------+------------------------------------------------------
 We are running a watchdog system that monitory backends an deaktivates
 backend by generation a on the fly config an upload it via controll
 conntection.

 This works quite well. After 3-4 Days the control connection stops working
 proberly. Not only the open one of the Watchdog, but every connection even
 newly opened ones.

 commands with larger outputs like vcl.list and help terminate prematurely.
 The remaining output lines are given bevor the output of the next command.

 I have attached a transcription of a example cli session.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/754>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 16 10:06:44 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 16 Aug 2010 10:06:44 -0000
Subject: [Varnish] #754: CLI communication error after some time running
In-Reply-To: <044.547964d2ae8acba825f355bf9b0bb5fd@varnish-cache.org>
References: <044.547964d2ae8acba825f355bf9b0bb5fd@varnish-cache.org>
Message-ID: <053.e6840abdedfa98faaa5ee473c528c085@varnish-cache.org>

#754: CLI communication error after some time running
---------------------+------------------------------------------------------
 Reporter:  Estartu  |        Type:  defect
   Status:  new      |    Priority:  normal
Milestone:           |   Component:  build 
  Version:  trunk    |    Severity:  normal
 Keywords:  cli      |  
---------------------+------------------------------------------------------

Comment(by phk):

 Just to verify, which exact version of Varnish are you running ?

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/754#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 16 11:12:14 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 16 Aug 2010 11:12:14 -0000
Subject: [Varnish] #753: Varnish craches
In-Reply-To: <049.e4871ddd65d5d7434dab456a42301aa3@varnish-cache.org>
References: <049.e4871ddd65d5d7434dab456a42301aa3@varnish-cache.org>
Message-ID: <058.4474e585c24bd41d7dcf3f251a23c248@varnish-cache.org>

#753: Varnish craches
--------------------------+-------------------------------------------------
 Reporter:  piripirigoso  |       Owner:  phk                
     Type:  defect        |      Status:  new                
 Priority:  highest       |   Milestone:  Varnish 2.1 release
Component:  varnishd      |     Version:  2.1.2              
 Severity:  major         |    Keywords:  Panic message      
--------------------------+-------------------------------------------------
Description changed by phk:

Old description:

> My installation's Varnish, has shown the following error:
>
> Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25313) died signal=6
> Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25313) Panic message:
> Assert error in WS_Release(), cache_ws.c line 193: Condition(bytes <=
> ws->e - ws->f) not true. thread = (cache-worker) ident =
> Linux,2.6.18-164.el5,x86_64,-sfile,-hcritbit,epoll Backtrace: 0x422616:
> /usr/sbin/varnishd [0x422616] 0x42d475:
> /usr/sbin/varnishd(WS_Release+0xf5) [0x42d475] 0x427b33:
> /usr/sbin/varnishd [0x427b33] 0x42bc45:
> /usr/sbin/varnishd(VRT_SetHdr+0xf5) [0x42bc45] 0x2ab1ab103b22:
> ./vcl.1P9zoqAU.so [0x2ab1ab103b22] 0x427693:
> /usr/sbin/varnishd(VCL_recv_method+0x43) [0x427693] 0x414097:
> /usr/sbin/varnishd(CNT_Session+0x5b7) [0x414097] 0x424a68:
> /usr/sbin/varnishd [0x424a68] 0x423d4d: /usr/sbin/varnishd [0x423d4d]
> 0x3028c064a7: /lib64/libpthread.so.0 [0x3028c064a7] sp = 0x2ab1f0b68008 {
> fd = 3143, id = 3143, xid = 1038927643, client = 187.78.137.224:3585,
> step = STP_RECV, handling = deliver, restarts = 0, esis = 0 ws =
> 0x2ab1f0b68078 { id = "sess", {s,f,r,e} =
> {0x2ab1f0b68c90,+63992,+65536,+65536}, }, http[req] = { ws =
> 0x2ab1f0b68078[sess] "GET", "/images/shopping/vitrine3.png", "HTTP/1.1",
> "Accept: */*", "Referer: http://clickjogos.uol.com.br/Jogos-
> online/Acao-e-Aventura/N/", "Accept-Language: pt-br", "User-Agent:
> Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0;
> InfoPath.2)", "If-Modified-Since: Tue, 27 Jul 2010 08:11:30 GMT", "Host:
> img3.clickjogos.uol.com.br", "Connection: Keep-Alive", "Accept-Encoding:
> gzip", "cookie:
> __utma=123316185.1934051457.1264250584.1280786857.1280789299.119;
> __utmz=123316185.1280787361.118.46.utmccn=(organic)|utmcsr=google|utmctr=batalha+site:clickjogos.uol.com.br|utmcmd=organic;
> RTRK.17=V1|1267445998450#6093e2f62552447c326e197e892b81417681ec3cd68189150f4c3c17479ee12585c2e39957281acde264efd989dd221953b764adc1720f0f8a99f90a0ffe628d3bac91a0173a4eb127fe63c358318b601c737adf1f0e881c6c749a03242176de638242c30e402136742b12b1aa471ffbf9cb3345c3c523840d7b4dad75948ea89dd689c11f169262fa50c5ac918e8d70c941fa0b34da53bc45696bf8759c310a8ef70a970ab1842d79dfa5360f8e72ea295b69197dfac07565c881544cc3c852d866cb5be3eb55fd91c96e37f9ab1e7dfc739d1c57542d5c9af278751bf3266cf58d04a43724028b5cf9d0560c0917005b3eccdfca9b31b38bf4c95a8cff262bf51a7497248882e8a485f9b8308395dcd1711e4e369cc2f66c218be448984d53;
> __gads=ID=f4b750b8c438c809:T=1262973373:S=ALNI_MYWYZTAE3jUHAI_Z4WCwBZ5T55zlg;
> ReachVita=0;
> RTRK.1=V1|1266418080111#ae0fa7ec6a4a1a1245c5a3dfc0c724e932a67502b32b66f406d270d8c54af4de22338f9923fe8924b986a9bb378a71a0522aecee1dcd1ffe8f40911aced5088837f2db46cca0321cf8c7fb62ed6cf68769b4a45be078301ec063e2f16efcced3c820a178f5a0f1f65b7f3eca97cbae2470a73825d03badcffe01cdcbd2577b1e5a9363c90324770b8043379c32e0c98b163afb0e93f19c56e2b69227ff949d58d19abc6cbce7b582592207ac1810e6a05a4f650522debee9392af7c31c715574;
> RTRK.11=V1|1266448187184#4d9a70ba92038ed4e090fc3904c454b81097d72c105f0a462cb9e2f73a74723beee4bdd4673d32224cbdaeff701da72b6c7bf603706ed1afde74c279a60eefae27c35509b4ca38704c2afefd12bf28dd2abc5899d3e60e094af9ce487b4af67fcab15518bdd0a8b11f00e7c7085f0a247d4d110bade850e05d6289dbcbe79006b59c934910a49de9120e3f76074159a5b12c9e8c260c64bba164669c2d7c96a79c66580fdef279005ec94f63b8f6aea8c5276c2094d124f4fb0ba4cfcd2446ce;
> RTRK.9=V1|1270922796677#af8668dddb8becb4b5caec582ed4e98e7e670a8091365f801c8ca4f79a16733d13c71001ab2ef7bc024ce006bc1174537fc978fb549c4fdb4ec126c80cc366f03443d90a99d035834842103b2d6ef369daaefed02c3bfb338b5a958c1d4ab81be0784d90c0fcf334a5981fc3202ad77e024cbe87ca719b0dc74c5f12243945a1bccee35f03f57e09fad3ae6a001a8fee6a0d814222ef89f89d4ce26c5bb937633e5e536c59379d1f526abf657517b113;
> uol_ut=187.78.1.149.1277569632060504; jogo_unique_user=1;
> RTRK.21=V1|1279490890283#bc24092a770d08eca70b9b1d80a1f6291097d72c105f0a462cb9e2f73a74723b213a8e283e624a65186a2d9ff1ef3fe81a65370d748419cf3579ce39be9310256b8d640f9cb9b0e72b6a2448e9c75879ddc288b08f8b31ada81becc286db2096957a4cf54a6241fdc46ce3ed50608af7c582b0fb73ecb75ae98b38294908e6670af7ccdaed3a3219019c99fcbd657b8b92c55bab47275ed1598e7908ac6446bc1dfa0dbfefb2c740b1c41b2b34b6697533b118d52bf757c3e24740ae73ce592b;
> RTRK.76=V1|1279542784635#6c938b0eee9eda23be11213ae0875fcc5d2fecf08491ca20d31fed160fb1faae9378b335f3eb2111c4eac5a5b63baa3ca2f6e012c2e8cc0b1626d3d07205ff7b08ff73021abc6b5a4600a6554ded25c244ce972f79c67e5e1b3d2568e34904406e36c42d1abf042b6740347e29c4e5ba;
> RTRK.12=V1|1280318741777#655a54020017f0210051bcdca62a80d07e670a8091365f801c8ca4f79a16733d92f559707ef8af746433345acc1c3cc69df958992f64587cfa30ce65414d0d2592ea3ffebed05d582dde09ff95f94ceb7cad96029c28e53fc363a28e496a669abaf6318f1fe193d11dfdb8ad3a3905f9b09540cdfe75145dacaf3c94b2c192ea5fcbe1d034b370743f468fc727666929dcc31f2e55ce1b52531aba83739985ad8d23f6188f53059234921bfcf164a8ef147be6e65fc79897d0f4d24d5fb3a4e8fbba015ae337ed8525095a6370eabf61fc6a99440a8a2a0b84632f30f536dce6b11d240a82c41c58443316d71cb59dca0b3a5cee2419c30572957e1437cd1a6f;
> AdUol=n+site:clickjogos.uol.com.br\www.google.com|SOCCER+STARS+site:clickjogos.uol.com.br\www.google.com|soccer%2520stars%2520no%2520click%2520jogos\www.google.com|soccer+star+site:clickjogos.uol.com.br\www.google.com|futebol+de+poderes+site:clickjogos.uol.com.br\www.google.com|;
> quietAlarms=1; 2t5i_unique_user=1", }, worker = 0x2ab2b9d02e60 { ws =
> 0x2ab2b9d02fc8 { id = "wrk", {s,f,r,e} =
> {0x2ab2b9cf0e10,0x2ab2b9cf0e10,(nil),+65536}, }, }, vcl = { srcname = {
> "input", "Default", "/etc/varnish/uolproxy_backend.vcl",
> "/etc/varnish/backend/virgula.vcl", "/etc/varnish/backend/videolog.vcl",
> "/etc/varnish/backend/hardgamer.vcl",
> "/etc/varnish/backend/trofeuinternet.vcl",
> "/etc/varnish/backend/cosmopax.vcl",
> "/etc/varnish/backend/clickjogos.vcl", }, }, },
> Aug 3 22:12:46 a2-mulher2 varnishd[13511]: child (25854) Started
> Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25854) said
> Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25854) said Child
> starts
> Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25854) said managed to
> mmap 30064771072 bytes of 3006477107
>
> Its happen once a two minutes.
>
> Any Ideia?

New description:

 My installation's Varnish, has shown the following error:
 {{{
 Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25313) died signal=6
 Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25313) Panic message:
 Assert error in WS_Release(), cache_ws.c line 193: Condition(bytes <=
 ws->e - ws->f) not true. thread = (cache-worker) ident =
 Linux,2.6.18-164.el5,x86_64,-sfile,-hcritbit,epoll Backtrace: 0x422616:
 /usr/sbin/varnishd [0x422616] 0x42d475:
 /usr/sbin/varnishd(WS_Release+0xf5) [0x42d475] 0x427b33:
 /usr/sbin/varnishd [0x427b33] 0x42bc45:
 /usr/sbin/varnishd(VRT_SetHdr+0xf5) [0x42bc45] 0x2ab1ab103b22:
 ./vcl.1P9zoqAU.so [0x2ab1ab103b22] 0x427693:
 /usr/sbin/varnishd(VCL_recv_method+0x43) [0x427693] 0x414097:
 /usr/sbin/varnishd(CNT_Session+0x5b7) [0x414097] 0x424a68:
 /usr/sbin/varnishd [0x424a68] 0x423d4d: /usr/sbin/varnishd [0x423d4d]
 0x3028c064a7: /lib64/libpthread.so.0 [0x3028c064a7] sp = 0x2ab1f0b68008 {
 fd = 3143, id = 3143, xid = 1038927643, client = 187.78.137.224:3585, step
 = STP_RECV, handling = deliver, restarts = 0, esis = 0 ws = 0x2ab1f0b68078
 { id = "sess", {s,f,r,e} = {0x2ab1f0b68c90,+63992,+65536,+65536}, },
 http[req] = { ws = 0x2ab1f0b68078[sess] "GET",
 "/images/shopping/vitrine3.png", "HTTP/1.1", "Accept: */*", "Referer:
 http://clickjogos.uol.com.br/Jogos-online/Acao-e-Aventura/N/", "Accept-
 Language: pt-br", "User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows
 NT 5.1; Trident/4.0; InfoPath.2)", "If-Modified-Since: Tue, 27 Jul 2010
 08:11:30 GMT", "Host: img3.clickjogos.uol.com.br", "Connection: Keep-
 Alive", "Accept-Encoding: gzip", "cookie:
 __utma=123316185.1934051457.1264250584.1280786857.1280789299.119;
 __utmz=123316185.1280787361.118.46.utmccn=(organic)|utmcsr=google|utmctr=batalha+site:clickjogos.uol.com.br|utmcmd=organic;
 RTRK.17=V1|1267445998450#6093e2f62552447c326e197e892b81417681ec3cd68189150f4c3c17479ee12585c2e39957281acde264efd989dd221953b764adc1720f0f8a99f90a0ffe628d3bac91a0173a4eb127fe63c358318b601c737adf1f0e881c6c749a03242176de638242c30e402136742b12b1aa471ffbf9cb3345c3c523840d7b4dad75948ea89dd689c11f169262fa50c5ac918e8d70c941fa0b34da53bc45696bf8759c310a8ef70a970ab1842d79dfa5360f8e72ea295b69197dfac07565c881544cc3c852d866cb5be3eb55fd91c96e37f9ab1e7dfc739d1c57542d5c9af278751bf3266cf58d04a43724028b5cf9d0560c0917005b3eccdfca9b31b38bf4c95a8cff262bf51a7497248882e8a485f9b8308395dcd1711e4e369cc2f66c218be448984d53;
 __gads=ID=f4b750b8c438c809:T=1262973373:S=ALNI_MYWYZTAE3jUHAI_Z4WCwBZ5T55zlg;
 ReachVita=0;
 RTRK.1=V1|1266418080111#ae0fa7ec6a4a1a1245c5a3dfc0c724e932a67502b32b66f406d270d8c54af4de22338f9923fe8924b986a9bb378a71a0522aecee1dcd1ffe8f40911aced5088837f2db46cca0321cf8c7fb62ed6cf68769b4a45be078301ec063e2f16efcced3c820a178f5a0f1f65b7f3eca97cbae2470a73825d03badcffe01cdcbd2577b1e5a9363c90324770b8043379c32e0c98b163afb0e93f19c56e2b69227ff949d58d19abc6cbce7b582592207ac1810e6a05a4f650522debee9392af7c31c715574;
 RTRK.11=V1|1266448187184#4d9a70ba92038ed4e090fc3904c454b81097d72c105f0a462cb9e2f73a74723beee4bdd4673d32224cbdaeff701da72b6c7bf603706ed1afde74c279a60eefae27c35509b4ca38704c2afefd12bf28dd2abc5899d3e60e094af9ce487b4af67fcab15518bdd0a8b11f00e7c7085f0a247d4d110bade850e05d6289dbcbe79006b59c934910a49de9120e3f76074159a5b12c9e8c260c64bba164669c2d7c96a79c66580fdef279005ec94f63b8f6aea8c5276c2094d124f4fb0ba4cfcd2446ce;
 RTRK.9=V1|1270922796677#af8668dddb8becb4b5caec582ed4e98e7e670a8091365f801c8ca4f79a16733d13c71001ab2ef7bc024ce006bc1174537fc978fb549c4fdb4ec126c80cc366f03443d90a99d035834842103b2d6ef369daaefed02c3bfb338b5a958c1d4ab81be0784d90c0fcf334a5981fc3202ad77e024cbe87ca719b0dc74c5f12243945a1bccee35f03f57e09fad3ae6a001a8fee6a0d814222ef89f89d4ce26c5bb937633e5e536c59379d1f526abf657517b113;
 uol_ut=187.78.1.149.1277569632060504; jogo_unique_user=1;
 RTRK.21=V1|1279490890283#bc24092a770d08eca70b9b1d80a1f6291097d72c105f0a462cb9e2f73a74723b213a8e283e624a65186a2d9ff1ef3fe81a65370d748419cf3579ce39be9310256b8d640f9cb9b0e72b6a2448e9c75879ddc288b08f8b31ada81becc286db2096957a4cf54a6241fdc46ce3ed50608af7c582b0fb73ecb75ae98b38294908e6670af7ccdaed3a3219019c99fcbd657b8b92c55bab47275ed1598e7908ac6446bc1dfa0dbfefb2c740b1c41b2b34b6697533b118d52bf757c3e24740ae73ce592b;
 RTRK.76=V1|1279542784635#6c938b0eee9eda23be11213ae0875fcc5d2fecf08491ca20d31fed160fb1faae9378b335f3eb2111c4eac5a5b63baa3ca2f6e012c2e8cc0b1626d3d07205ff7b08ff73021abc6b5a4600a6554ded25c244ce972f79c67e5e1b3d2568e34904406e36c42d1abf042b6740347e29c4e5ba;
 RTRK.12=V1|1280318741777#655a54020017f0210051bcdca62a80d07e670a8091365f801c8ca4f79a16733d92f559707ef8af746433345acc1c3cc69df958992f64587cfa30ce65414d0d2592ea3ffebed05d582dde09ff95f94ceb7cad96029c28e53fc363a28e496a669abaf6318f1fe193d11dfdb8ad3a3905f9b09540cdfe75145dacaf3c94b2c192ea5fcbe1d034b370743f468fc727666929dcc31f2e55ce1b52531aba83739985ad8d23f6188f53059234921bfcf164a8ef147be6e65fc79897d0f4d24d5fb3a4e8fbba015ae337ed8525095a6370eabf61fc6a99440a8a2a0b84632f30f536dce6b11d240a82c41c58443316d71cb59dca0b3a5cee2419c30572957e1437cd1a6f;
 AdUol=n+site:clickjogos.uol.com.br\www.google.com|SOCCER+STARS+site:clickjogos.uol.com.br\www.google.com|soccer%2520stars%2520no%2520click%2520jogos\www.google.com|soccer+star+site:clickjogos.uol.com.br\www.google.com|futebol+de+poderes+site:clickjogos.uol.com.br\www.google.com|;
 quietAlarms=1; 2t5i_unique_user=1", }, worker = 0x2ab2b9d02e60 { ws =
 0x2ab2b9d02fc8 { id = "wrk", {s,f,r,e} =
 {0x2ab2b9cf0e10,0x2ab2b9cf0e10,(nil),+65536}, }, }, vcl = { srcname = {
 "input", "Default", "/etc/varnish/uolproxy_backend.vcl",
 "/etc/varnish/backend/virgula.vcl", "/etc/varnish/backend/videolog.vcl",
 "/etc/varnish/backend/hardgamer.vcl",
 "/etc/varnish/backend/trofeuinternet.vcl",
 "/etc/varnish/backend/cosmopax.vcl",
 "/etc/varnish/backend/clickjogos.vcl", }, }, },
 Aug 3 22:12:46 a2-mulher2 varnishd[13511]: child (25854) Started
 Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25854) said
 Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25854) said Child starts
 Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25854) said managed to
 mmap 30064771072 bytes of 3006477107
 }}}
 Its happen once a two minutes.

 Any Ideia?

--

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/753#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 16 11:15:33 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 16 Aug 2010 11:15:33 -0000
Subject: [Varnish] #753: Varnish craches
In-Reply-To: <049.e4871ddd65d5d7434dab456a42301aa3@varnish-cache.org>
References: <049.e4871ddd65d5d7434dab456a42301aa3@varnish-cache.org>
Message-ID: <058.1ed3442128c3605613835bb5bc6a59ad@varnish-cache.org>

#753: Varnish craches
--------------------------+-------------------------------------------------
 Reporter:  piripirigoso  |       Owner:  phk                
     Type:  defect        |      Status:  new                
 Priority:  highest       |   Milestone:  Varnish 2.1 release
Component:  varnishd      |     Version:  2.1.2              
 Severity:  major         |    Keywords:  Panic message      
--------------------------+-------------------------------------------------
Description changed by phk:

Old description:

> My installation's Varnish, has shown the following error:
> {{{
> Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25313) died signal=6
> Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25313) Panic message:
> Assert error in WS_Release(), cache_ws.c line 193: Condition(bytes <=
> ws->e - ws->f) not true. thread = (cache-worker) ident =
> Linux,2.6.18-164.el5,x86_64,-sfile,-hcritbit,epoll Backtrace: 0x422616:
> /usr/sbin/varnishd [0x422616] 0x42d475:
> /usr/sbin/varnishd(WS_Release+0xf5) [0x42d475] 0x427b33:
> /usr/sbin/varnishd [0x427b33] 0x42bc45:
> /usr/sbin/varnishd(VRT_SetHdr+0xf5) [0x42bc45] 0x2ab1ab103b22:
> ./vcl.1P9zoqAU.so [0x2ab1ab103b22] 0x427693:
> /usr/sbin/varnishd(VCL_recv_method+0x43) [0x427693] 0x414097:
> /usr/sbin/varnishd(CNT_Session+0x5b7) [0x414097] 0x424a68:
> /usr/sbin/varnishd [0x424a68] 0x423d4d: /usr/sbin/varnishd [0x423d4d]
> 0x3028c064a7: /lib64/libpthread.so.0 [0x3028c064a7] sp = 0x2ab1f0b68008 {
> fd = 3143, id = 3143, xid = 1038927643, client = 187.78.137.224:3585,
> step = STP_RECV, handling = deliver, restarts = 0, esis = 0 ws =
> 0x2ab1f0b68078 { id = "sess", {s,f,r,e} =
> {0x2ab1f0b68c90,+63992,+65536,+65536}, }, http[req] = { ws =
> 0x2ab1f0b68078[sess] "GET", "/images/shopping/vitrine3.png", "HTTP/1.1",
> "Accept: */*", "Referer: http://clickjogos.uol.com.br/Jogos-
> online/Acao-e-Aventura/N/", "Accept-Language: pt-br", "User-Agent:
> Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0;
> InfoPath.2)", "If-Modified-Since: Tue, 27 Jul 2010 08:11:30 GMT", "Host:
> img3.clickjogos.uol.com.br", "Connection: Keep-Alive", "Accept-Encoding:
> gzip", "cookie:
> __utma=123316185.1934051457.1264250584.1280786857.1280789299.119;
> __utmz=123316185.1280787361.118.46.utmccn=(organic)|utmcsr=google|utmctr=batalha+site:clickjogos.uol.com.br|utmcmd=organic;
> RTRK.17=V1|1267445998450#6093e2f62552447c326e197e892b81417681ec3cd68189150f4c3c17479ee12585c2e39957281acde264efd989dd221953b764adc1720f0f8a99f90a0ffe628d3bac91a0173a4eb127fe63c358318b601c737adf1f0e881c6c749a03242176de638242c30e402136742b12b1aa471ffbf9cb3345c3c523840d7b4dad75948ea89dd689c11f169262fa50c5ac918e8d70c941fa0b34da53bc45696bf8759c310a8ef70a970ab1842d79dfa5360f8e72ea295b69197dfac07565c881544cc3c852d866cb5be3eb55fd91c96e37f9ab1e7dfc739d1c57542d5c9af278751bf3266cf58d04a43724028b5cf9d0560c0917005b3eccdfca9b31b38bf4c95a8cff262bf51a7497248882e8a485f9b8308395dcd1711e4e369cc2f66c218be448984d53;
> __gads=ID=f4b750b8c438c809:T=1262973373:S=ALNI_MYWYZTAE3jUHAI_Z4WCwBZ5T55zlg;
> ReachVita=0;
> RTRK.1=V1|1266418080111#ae0fa7ec6a4a1a1245c5a3dfc0c724e932a67502b32b66f406d270d8c54af4de22338f9923fe8924b986a9bb378a71a0522aecee1dcd1ffe8f40911aced5088837f2db46cca0321cf8c7fb62ed6cf68769b4a45be078301ec063e2f16efcced3c820a178f5a0f1f65b7f3eca97cbae2470a73825d03badcffe01cdcbd2577b1e5a9363c90324770b8043379c32e0c98b163afb0e93f19c56e2b69227ff949d58d19abc6cbce7b582592207ac1810e6a05a4f650522debee9392af7c31c715574;
> RTRK.11=V1|1266448187184#4d9a70ba92038ed4e090fc3904c454b81097d72c105f0a462cb9e2f73a74723beee4bdd4673d32224cbdaeff701da72b6c7bf603706ed1afde74c279a60eefae27c35509b4ca38704c2afefd12bf28dd2abc5899d3e60e094af9ce487b4af67fcab15518bdd0a8b11f00e7c7085f0a247d4d110bade850e05d6289dbcbe79006b59c934910a49de9120e3f76074159a5b12c9e8c260c64bba164669c2d7c96a79c66580fdef279005ec94f63b8f6aea8c5276c2094d124f4fb0ba4cfcd2446ce;
> RTRK.9=V1|1270922796677#af8668dddb8becb4b5caec582ed4e98e7e670a8091365f801c8ca4f79a16733d13c71001ab2ef7bc024ce006bc1174537fc978fb549c4fdb4ec126c80cc366f03443d90a99d035834842103b2d6ef369daaefed02c3bfb338b5a958c1d4ab81be0784d90c0fcf334a5981fc3202ad77e024cbe87ca719b0dc74c5f12243945a1bccee35f03f57e09fad3ae6a001a8fee6a0d814222ef89f89d4ce26c5bb937633e5e536c59379d1f526abf657517b113;
> uol_ut=187.78.1.149.1277569632060504; jogo_unique_user=1;
> RTRK.21=V1|1279490890283#bc24092a770d08eca70b9b1d80a1f6291097d72c105f0a462cb9e2f73a74723b213a8e283e624a65186a2d9ff1ef3fe81a65370d748419cf3579ce39be9310256b8d640f9cb9b0e72b6a2448e9c75879ddc288b08f8b31ada81becc286db2096957a4cf54a6241fdc46ce3ed50608af7c582b0fb73ecb75ae98b38294908e6670af7ccdaed3a3219019c99fcbd657b8b92c55bab47275ed1598e7908ac6446bc1dfa0dbfefb2c740b1c41b2b34b6697533b118d52bf757c3e24740ae73ce592b;
> RTRK.76=V1|1279542784635#6c938b0eee9eda23be11213ae0875fcc5d2fecf08491ca20d31fed160fb1faae9378b335f3eb2111c4eac5a5b63baa3ca2f6e012c2e8cc0b1626d3d07205ff7b08ff73021abc6b5a4600a6554ded25c244ce972f79c67e5e1b3d2568e34904406e36c42d1abf042b6740347e29c4e5ba;
> RTRK.12=V1|1280318741777#655a54020017f0210051bcdca62a80d07e670a8091365f801c8ca4f79a16733d92f559707ef8af746433345acc1c3cc69df958992f64587cfa30ce65414d0d2592ea3ffebed05d582dde09ff95f94ceb7cad96029c28e53fc363a28e496a669abaf6318f1fe193d11dfdb8ad3a3905f9b09540cdfe75145dacaf3c94b2c192ea5fcbe1d034b370743f468fc727666929dcc31f2e55ce1b52531aba83739985ad8d23f6188f53059234921bfcf164a8ef147be6e65fc79897d0f4d24d5fb3a4e8fbba015ae337ed8525095a6370eabf61fc6a99440a8a2a0b84632f30f536dce6b11d240a82c41c58443316d71cb59dca0b3a5cee2419c30572957e1437cd1a6f;
> AdUol=n+site:clickjogos.uol.com.br\www.google.com|SOCCER+STARS+site:clickjogos.uol.com.br\www.google.com|soccer%2520stars%2520no%2520click%2520jogos\www.google.com|soccer+star+site:clickjogos.uol.com.br\www.google.com|futebol+de+poderes+site:clickjogos.uol.com.br\www.google.com|;
> quietAlarms=1; 2t5i_unique_user=1", }, worker = 0x2ab2b9d02e60 { ws =
> 0x2ab2b9d02fc8 { id = "wrk", {s,f,r,e} =
> {0x2ab2b9cf0e10,0x2ab2b9cf0e10,(nil),+65536}, }, }, vcl = { srcname = {
> "input", "Default", "/etc/varnish/uolproxy_backend.vcl",
> "/etc/varnish/backend/virgula.vcl", "/etc/varnish/backend/videolog.vcl",
> "/etc/varnish/backend/hardgamer.vcl",
> "/etc/varnish/backend/trofeuinternet.vcl",
> "/etc/varnish/backend/cosmopax.vcl",
> "/etc/varnish/backend/clickjogos.vcl", }, }, },
> Aug 3 22:12:46 a2-mulher2 varnishd[13511]: child (25854) Started
> Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25854) said
> Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25854) said Child
> starts
> Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25854) said managed to
> mmap 30064771072 bytes of 3006477107
> }}}
> Its happen once a two minutes.
>
> Any Ideia?

New description:

 My installation's Varnish, has shown the following error:
 {{{
 Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25313) died signal=6
 Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25313)
  Panic message: Assert error in WS_Release(), cache_ws.c line 193:
  Condition(bytes <= ws->e - ws->f) not true.
  thread = (cache-worker)
  ident = Linux,2.6.18-164.el5,x86_64,-sfile,-hcritbit,epoll Backtrace:
  0x422616: /usr/sbin/varnishd [0x422616]
  0x42d475: /usr/sbin/varnishd(WS_Release+0xf5) [0x42d475]
  0x427b33: /usr/sbin/varnishd [0x427b33]
  0x42bc45: /usr/sbin/varnishd(VRT_SetHdr+0xf5) [0x42bc45]
  0x2ab1ab103b22: ./vcl.1P9zoqAU.so [0x2ab1ab103b22]
  0x427693: /usr/sbin/varnishd(VCL_recv_method+0x43) [0x427693]
  0x414097: /usr/sbin/varnishd(CNT_Session+0x5b7) [0x414097]
  0x424a68: /usr/sbin/varnishd [0x424a68]
  0x423d4d: /usr/sbin/varnishd [0x423d4d]
  0x3028c064a7: /lib64/libpthread.so.0 [0x3028c064a7]
  sp = 0x2ab1f0b68008 {
    fd = 3143, id = 3143, xid = 1038927643,
    client = 187.78.137.224:3585,
    step = STP_RECV, handling = deliver,
    restarts = 0, esis = 0
    ws = 0x2ab1f0b68078 {
      id = "sess", {s,f,r,e} = {0x2ab1f0b68c90,+63992,+65536,+65536},
    },
    http[req] = {
      ws = 0x2ab1f0b68078[sess]
      "GET", "/images/shopping/vitrine3.png", "HTTP/1.1",
      "Accept: */*", "Referer: http://clickjogos.uol.com.br/Jogos-
 online/Acao-e-Aventura/N/", "Accept-Language: pt-br", "User-Agent:
 Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0;
 InfoPath.2)", "If-Modified-Since: Tue, 27 Jul 2010 08:11:30 GMT", "Host:
 img3.clickjogos.uol.com.br", "Connection: Keep-Alive", "Accept-Encoding:
 gzip", "cookie:
 __utma=123316185.1934051457.1264250584.1280786857.1280789299.119;
 __utmz=123316185.1280787361.118.46.utmccn=(organic)|utmcsr=google|utmctr=batalha+site:clickjogos.uol.com.br|utmcmd=organic;
 RTRK.17=V1|1267445998450#6093e2f62552447c326e197e892b81417681ec3cd68189150f4c3c17479ee12585c2e39957281acde264efd989dd221953b764adc1720f0f8a99f90a0ffe628d3bac91a0173a4eb127fe63c358318b601c737adf1f0e881c6c749a03242176de638242c30e402136742b12b1aa471ffbf9cb3345c3c523840d7b4dad75948ea89dd689c11f169262fa50c5ac918e8d70c941fa0b34da53bc45696bf8759c310a8ef70a970ab1842d79dfa5360f8e72ea295b69197dfac07565c881544cc3c852d866cb5be3eb55fd91c96e37f9ab1e7dfc739d1c57542d5c9af278751bf3266cf58d04a43724028b5cf9d0560c0917005b3eccdfca9b31b38bf4c95a8cff262bf51a7497248882e8a485f9b8308395dcd1711e4e369cc2f66c218be448984d53;
 __gads=ID=f4b750b8c438c809:T=1262973373:S=ALNI_MYWYZTAE3jUHAI_Z4WCwBZ5T55zlg;
 ReachVita=0;
 RTRK.1=V1|1266418080111#ae0fa7ec6a4a1a1245c5a3dfc0c724e932a67502b32b66f406d270d8c54af4de22338f9923fe8924b986a9bb378a71a0522aecee1dcd1ffe8f40911aced5088837f2db46cca0321cf8c7fb62ed6cf68769b4a45be078301ec063e2f16efcced3c820a178f5a0f1f65b7f3eca97cbae2470a73825d03badcffe01cdcbd2577b1e5a9363c90324770b8043379c32e0c98b163afb0e93f19c56e2b69227ff949d58d19abc6cbce7b582592207ac1810e6a05a4f650522debee9392af7c31c715574;
 RTRK.11=V1|1266448187184#4d9a70ba92038ed4e090fc3904c454b81097d72c105f0a462cb9e2f73a74723beee4bdd4673d32224cbdaeff701da72b6c7bf603706ed1afde74c279a60eefae27c35509b4ca38704c2afefd12bf28dd2abc5899d3e60e094af9ce487b4af67fcab15518bdd0a8b11f00e7c7085f0a247d4d110bade850e05d6289dbcbe79006b59c934910a49de9120e3f76074159a5b12c9e8c260c64bba164669c2d7c96a79c66580fdef279005ec94f63b8f6aea8c5276c2094d124f4fb0ba4cfcd2446ce;
 RTRK.9=V1|1270922796677#af8668dddb8becb4b5caec582ed4e98e7e670a8091365f801c8ca4f79a16733d13c71001ab2ef7bc024ce006bc1174537fc978fb549c4fdb4ec126c80cc366f03443d90a99d035834842103b2d6ef369daaefed02c3bfb338b5a958c1d4ab81be0784d90c0fcf334a5981fc3202ad77e024cbe87ca719b0dc74c5f12243945a1bccee35f03f57e09fad3ae6a001a8fee6a0d814222ef89f89d4ce26c5bb937633e5e536c59379d1f526abf657517b113;
 uol_ut=187.78.1.149.1277569632060504; jogo_unique_user=1;
 RTRK.21=V1|1279490890283#bc24092a770d08eca70b9b1d80a1f6291097d72c105f0a462cb9e2f73a74723b213a8e283e624a65186a2d9ff1ef3fe81a65370d748419cf3579ce39be9310256b8d640f9cb9b0e72b6a2448e9c75879ddc288b08f8b31ada81becc286db2096957a4cf54a6241fdc46ce3ed50608af7c582b0fb73ecb75ae98b38294908e6670af7ccdaed3a3219019c99fcbd657b8b92c55bab47275ed1598e7908ac6446bc1dfa0dbfefb2c740b1c41b2b34b6697533b118d52bf757c3e24740ae73ce592b;
 RTRK.76=V1|1279542784635#6c938b0eee9eda23be11213ae0875fcc5d2fecf08491ca20d31fed160fb1faae9378b335f3eb2111c4eac5a5b63baa3ca2f6e012c2e8cc0b1626d3d07205ff7b08ff73021abc6b5a4600a6554ded25c244ce972f79c67e5e1b3d2568e34904406e36c42d1abf042b6740347e29c4e5ba;
 RTRK.12=V1|1280318741777#655a54020017f0210051bcdca62a80d07e670a8091365f801c8ca4f79a16733d92f559707ef8af746433345acc1c3cc69df958992f64587cfa30ce65414d0d2592ea3ffebed05d582dde09ff95f94ceb7cad96029c28e53fc363a28e496a669abaf6318f1fe193d11dfdb8ad3a3905f9b09540cdfe75145dacaf3c94b2c192ea5fcbe1d034b370743f468fc727666929dcc31f2e55ce1b52531aba83739985ad8d23f6188f53059234921bfcf164a8ef147be6e65fc79897d0f4d24d5fb3a4e8fbba015ae337ed8525095a6370eabf61fc6a99440a8a2a0b84632f30f536dce6b11d240a82c41c58443316d71cb59dca0b3a5cee2419c30572957e1437cd1a6f;
 AdUol=n+site:clickjogos.uol.com.br\www.google.com|SOCCER+STARS+site:clickjogos.uol.com.br\www.google.com|soccer%2520stars%2520no%2520click%2520jogos\www.google.com|soccer+star+site:clickjogos.uol.com.br\www.google.com|futebol+de+poderes+site:clickjogos.uol.com.br\www.google.com|;
 quietAlarms=1; 2t5i_unique_user=1", }, worker = 0x2ab2b9d02e60 { ws =
 0x2ab2b9d02fc8 { id = "wrk", {s,f,r,e} =
 {0x2ab2b9cf0e10,0x2ab2b9cf0e10,(nil),+65536}, }, }, vcl = { srcname = {
 "input", "Default", "/etc/varnish/uolproxy_backend.vcl",
 "/etc/varnish/backend/virgula.vcl", "/etc/varnish/backend/videolog.vcl",
 "/etc/varnish/backend/hardgamer.vcl",
 "/etc/varnish/backend/trofeuinternet.vcl",
 "/etc/varnish/backend/cosmopax.vcl",
 "/etc/varnish/backend/clickjogos.vcl", }, }, },
 Aug 3 22:12:46 a2-mulher2 varnishd[13511]: child (25854) Started
 Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25854) said
 Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25854) said Child starts
 Aug 3 22:12:46 a2-mulher2 varnishd[13511]: Child (25854) said managed to
 mmap 30064771072 bytes of 3006477107
 }}}
 Its happen once a two minutes.

 Any Ideia?

--

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/753#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 16 11:25:49 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 16 Aug 2010 11:25:49 -0000
Subject: [Varnish] #753: Varnish craches
In-Reply-To: <049.e4871ddd65d5d7434dab456a42301aa3@varnish-cache.org>
References: <049.e4871ddd65d5d7434dab456a42301aa3@varnish-cache.org>
Message-ID: <058.d23f839874dcaf5a839a8e404e84f791@varnish-cache.org>

#753: Varnish craches
---------------------------+------------------------------------------------
 Reporter:  piripirigoso   |        Owner:  phk                
     Type:  defect         |       Status:  closed             
 Priority:  highest        |    Milestone:  Varnish 2.1 release
Component:  varnishd       |      Version:  2.1.2              
 Severity:  major          |   Resolution:  worksforme         
 Keywords:  Panic message  |  
---------------------------+------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => worksforme


Comment:

 It looks like those massive cookies overrun your session workspace.

 Try increasing the sess_workspace parameter, that should help.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/753#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 16 11:44:40 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 16 Aug 2010 11:44:40 -0000
Subject: [Varnish] #754: CLI communication error after some time running
In-Reply-To: <044.547964d2ae8acba825f355bf9b0bb5fd@varnish-cache.org>
References: <044.547964d2ae8acba825f355bf9b0bb5fd@varnish-cache.org>
Message-ID: <053.63ba9bb0183e7574d08d815ae71e2e98@varnish-cache.org>

#754: CLI communication error after some time running
---------------------+------------------------------------------------------
 Reporter:  Estartu  |        Type:  defect
   Status:  new      |    Priority:  normal
Milestone:           |   Component:  build 
  Version:  trunk    |    Severity:  normal
 Keywords:  cli      |  
---------------------+------------------------------------------------------

Comment(by Estartu):

 varnishd (varnish-2.1.3 SVN 5049:5055)
 Copyright (c) 2006-2009 Linpro AS / Verdens Gang AS

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/754#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Aug 17 12:25:23 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 17 Aug 2010 12:25:23 -0000
Subject: [Varnish] #736: Migration to Cygwin plataform
In-Reply-To: <042.6ef2981e8cf7eb068adf1551551220f4@varnish-cache.org>
References: <042.6ef2981e8cf7eb068adf1551551220f4@varnish-cache.org>
Message-ID: <051.59daee422959fda96f5845b04559f429@varnish-cache.org>

#736: Migration to Cygwin plataform
----------------------+-----------------------------------------------------
  Reporter:  jdzst    |        Type:  enhancement    
    Status:  closed   |    Priority:  normal         
 Milestone:           |   Component:  build          
   Version:           |    Severity:  normal         
Resolution:  invalid  |    Keywords:  cygwin, windows
----------------------+-----------------------------------------------------

Comment(by jdzst):

 I have attached cygwin changes in patch format for r5110.

 I also have executed regression tests with r5110. I continue having
 problems with:

 {{{
 FAIL: ./tests/b00004.vtc
 FAIL: ./tests/b00015.vtc
 FAIL: ./tests/b00030.vtc
 FAIL: ./tests/c00005.vtc
 FAIL: ./tests/p00002.vtc
 FAIL: ./tests/r00433.vtc
 FAIL: ./tests/r00558.vtc
 FAIL: ./tests/v00009.vtc
 FAIL: ./tests/v00027.vtc
 }}}

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/736#comment:8>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Aug 17 12:27:27 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 17 Aug 2010 12:27:27 -0000
Subject: [Varnish] #736: Migration to Cygwin plataform
In-Reply-To: <042.6ef2981e8cf7eb068adf1551551220f4@varnish-cache.org>
References: <042.6ef2981e8cf7eb068adf1551551220f4@varnish-cache.org>
Message-ID: <051.9df9f610c3e1bad7b91e296bb941da6d@varnish-cache.org>

#736: Migration to Cygwin plataform
----------------------+-----------------------------------------------------
  Reporter:  jdzst    |        Type:  enhancement    
    Status:  closed   |    Priority:  normal         
 Milestone:           |   Component:  build          
   Version:           |    Severity:  normal         
Resolution:  invalid  |    Keywords:  cygwin, windows
----------------------+-----------------------------------------------------

Comment(by jdzst):

 c00005.vtc test fails because there is a IPv6 instruction "::" in VCL that
 it is not supported by Cygwin in Windows XP:

 {{{
         acl acl1 {
                 ! "localhost";
                 "0.0.0.0" / 0;
                 "::" / 0;
         }
 }}}

 {{{
 **** v1   CLI RX| DNS lookup(::): hostname nor servname provided, or not
 known\n
 }}}

 Cygwin IPv6 might work in Windows Vista (but I don't have any)

 http://www.cygwin.com/cygwin-ug-net/ov-new1.7.html

 {{{
 IPv6 support. New APIs getaddrinfo, getnameinfo, freeaddrinfo,
 gai_strerror, in6addr_any, in6addr_loopback. On IPv6-less systems,
 replacement functions are available for IPv4. On systems with IPv6
 enabled, the underlying WinSock functions are used. While I tried hard to
 get the functionality as POSIXy as possible, keep in mind that a *fully*
 conformant implementation of getaddrinfo and other stuff is only available
 starting with Windows Vista/2008.
 }}}

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/736#comment:9>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Aug 17 12:29:11 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 17 Aug 2010 12:29:11 -0000
Subject: [Varnish] #736: Migration to Cygwin plataform
In-Reply-To: <042.6ef2981e8cf7eb068adf1551551220f4@varnish-cache.org>
References: <042.6ef2981e8cf7eb068adf1551551220f4@varnish-cache.org>
Message-ID: <051.9607edd61a8e8eaded485fc6dbbfc719@varnish-cache.org>

#736: Migration to Cygwin plataform
----------------------+-----------------------------------------------------
  Reporter:  jdzst    |        Type:  enhancement    
    Status:  closed   |    Priority:  normal         
 Milestone:           |   Component:  build          
   Version:           |    Severity:  normal         
Resolution:  invalid  |    Keywords:  cygwin, windows
----------------------+-----------------------------------------------------

Comment(by jdzst):

 Cygwin IPv6 might work in Windows Vista (but I don't have any)

  http://www.cygwin.com/cygwin-ug-net/ov-new1.7.html

 IPv6 support. New APIs getaddrinfo, getnameinfo, freeaddrinfo,
 gai_strerror, in6addr_any, in6addr_loopback. On IPv6-less systems,
 replacement functions are available for IPv4.
 On systems with IPv6 enabled, the underlying WinSock functions are used.
 While I tried hard to get the functionality as POSIXy as possible, keep in
 mind that a *fully* conformant implementation of getaddrinfo and other
 stuff is only available starting with Windows Vista/2008.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/736#comment:10>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug 18 15:52:16 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 18 Aug 2010 15:52:16 -0000
Subject: [Varnish] #755: Incorrect escaping of purges
Message-ID: <045.170f5c50b281940c10f9c218b24bde03@varnish-cache.org>

#755: Incorrect escaping of purges
----------------------+-----------------------------------------------------
 Reporter:  kristian  |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  trunk
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
 There's double-escaping going on (I'll track it down when this course is
 over) when it comes to purges. Example:

 {{{
 purge req.url ~ "\.css"
 100 85
 Unknown request.
 Type 'help' for more info.
 Syntax Error: Invalid backslash sequence

 purge req.url ~ "\\.css"
 200 0

 purge.list
 200 152
 0x7fa2bd20d9a0 1282146548.428008     0  req.url ~ \.css
 0x7fa2bd20db20 1282145619.939903     1  req.url ~ /two
 0x7fa2bd20d580 1282145596.146903     2G
 }}}

 PCRE can take care of \.foo, but Varnish can't. (I already did track this
 down, but forgot to report/fix/write it down, so I'm being pre-emptive).

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/755>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Aug 19 10:58:04 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 19 Aug 2010 10:58:04 -0000
Subject: [Varnish] #503: Assertion failure when trying to fetch a large
	object
In-Reply-To: <042.bfb93c0a3a64fb8d4e65b2516c286a37@varnish-cache.org>
References: <042.bfb93c0a3a64fb8d4e65b2516c286a37@varnish-cache.org>
Message-ID: <051.694a3e4f0bd3cf009fa80dd4bfcfe810@varnish-cache.org>

#503: Assertion failure when trying to fetch a large object
----------------------+-----------------------------------------------------
  Reporter:  Sesse    |        Type:  defect
    Status:  closed   |    Priority:  normal
 Milestone:           |   Component:  build 
   Version:  trunk    |    Severity:  normal
Resolution:  wontfix  |    Keywords:        
----------------------+-----------------------------------------------------

Comment(by leki):

 We have the same problem with latest 2.1.3 version. When I try to download
 the 2.4g file varnishd panics.

 {{{
 Aug 19 10:28:17 fe01a swbazis[15514]: Child (16628) Panic message: Assert
 error in STV_alloc(), stevedore.c line 192:   Condition((st) != NULL) not
 true. thread = (cache-worker) ident = Linux,2.6.26-2-xen-
 amd64,x86_64,-sfile,-sfile,-sfile,-hcritbit,epoll Backtrace:   0x424608:
 /usr/sbin/varnishd [0x424608]   0x43a215:
 /usr/sbin/varnishd(STV_alloc+0x175) [0x43a215]   0x41c2e4:
 /usr/sbin/varnishd(FetchBody+0x4c4) [0x41c2e4]   0x413b60:
 /usr/sbin/varnishd [0x413b60]   0x415135:
 /usr/sbin/varnishd(CNT_Session+0x315) [0x415135]   0x426a48:
 /usr/sbin/varnishd [0x426a48]   0x425d23: /usr/sbin/varnishd [0x425d23]
 0x7fa51b0c6fc7: /lib/libpthread.so.0 [0x7fa51b0c6fc7]   0x7fa51a9a164d:
 /lib/libc.so.6(clone+0x6d) [0x7fa51a9a164d] sp = 0x7f5a1370a008 {   fd =
 20, id = 20, xid = 1016964835,   client = 172.27.128.73:42035,   step =
 STP_FETCH,   handling = deliver,   err_code = 200, err_reason = (null),
 restarts = 0, esis = 0   ws = 0x7f5a1370a078 {      id = "sess",
 {s,f,r,e} = {0x7f5a1370acd0,+1016,(nil),+65536},   },   http[req] = {
 ws = 0x7f5a1370a078[sess]       "GET",       ...  },   worker = 0x4700ce70
 {     ws = 0x4700cfe0 {        id = "wrk",       {s,f,r,e} =
 {0x46ffae10,+4432,(nil),+65536},     },     http[bereq] = {       ws =
 0x4700cfe0[wrk]         "GET",         ...    },     http[beresp] = {
 ws = 0x4700cfe0[wrk]         "HTTP/1.1",         "200",         "OK",
 "Date: Thu, 19 Aug 2010 10:28:17 GMT",         "Content-Type:
 application/x-rar-compressed",         '''"Content-Length: 2470522946"''',
 "Last-Modified: Sat, 13 Feb 2010 18:10:52 GMT",         "Connection:
 close",         "Accept-Ranges: bytes",         "Cache-Control: max-
 age=86400",         "Server: Microsoft-IIS/6.0",     },     },     vcl = {
 srcname = {         "input",         "Default",       },     },   obj =
 0x7f8be27fe000 {     xid = 1016964835,     ws = 0x7f8be27fe020 {        id
 = "obj",       {s,f,r,e} = {0x7f8be27fe208,+232,(nil),+3576},     },
 http[obj] = {       ws = 0x7f8be27fe020[obj]         "HTTP/1.1",
 "200",         "OK",         "Date: Thu, 19 Aug 2010 10:28:17 GMT",
 "Content-Type: application/x-rar-compressed",         "Last-Modified: Sat,
 13 Feb 2010 18:10:52 GMT",         "Cache-Control: max-age=86400",
 "Server: Microsoft-IIS/6.0",     },     len = 0,     store = {     },   },
 },
 }}}


 My storage space is quite huge so it should not be the problem:
              -s file,/cache1/varnish.bin,100G
              -s file,/cache2/varnish.bin,100G
              -s file,/cache3/varnish.bin,100G

 Vanishstat says:
   1651228672          .            .   bytes allocated
 320471318528          .            .   bytes free

 Downloading the big file anytime causes varnishd to restart clearing all
 varnishstat counters.

 vcl_prefetch is removed in 2.1 and return(pipe) is not allowed in
 vcl_fetch.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/503#comment:9>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Aug 19 20:13:31 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 19 Aug 2010 20:13:31 -0000
Subject: [Varnish] #756: tests/c00031.vtc fails on RHEL6 beta2 / ppc64
Message-ID: <043.e34ebfca87896c1671e8c328f47fa932@varnish-cache.org>

#756: tests/c00031.vtc fails on RHEL6 beta2 / ppc64
--------------------+-------------------------------------------------------
 Reporter:  ingvar  |       Owner:       
     Type:  defect  |      Status:  new  
 Priority:  normal  |   Milestone:       
Component:  build   |     Version:  trunk
 Severity:  normal  |    Keywords:       
--------------------+-------------------------------------------------------
 When running make check for varnish-2.1.3 on rhel6 beta2/ppc64,
 tests/c00031.vtc fails. This has to work to get varnish into epel6.

 See attached output from make check.

 This was set to trunk since 2.1.3 is not available in the version list in
 the trac.

 Ingvar

-- 
Ticket URL: <http://varnish-cache.org/ticket/756>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Aug 19 20:14:52 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 19 Aug 2010 20:14:52 -0000
Subject: [Varnish] #756: tests/c00031.vtc fails on RHEL6 beta2 / ppc64
In-Reply-To: <043.e34ebfca87896c1671e8c328f47fa932@varnish-cache.org>
References: <043.e34ebfca87896c1671e8c328f47fa932@varnish-cache.org>
Message-ID: <052.22affc133444a69db3043c6d911c55ec@varnish-cache.org>

#756: tests/c00031.vtc fails on RHEL6 beta2 / ppc64
--------------------+-------------------------------------------------------
 Reporter:  ingvar  |       Owner:       
     Type:  defect  |      Status:  new  
 Priority:  normal  |   Milestone:       
Component:  build   |     Version:  2.1.3
 Severity:  normal  |    Keywords:       
--------------------+-------------------------------------------------------
Changes (by ingvar):

  * version:  trunk => 2.1.3


-- 
Ticket URL: <http://varnish-cache.org/ticket/756#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Aug 19 20:15:09 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 19 Aug 2010 20:15:09 -0000
Subject: [Varnish] #756: tests/c00031.vtc fails on RHEL6 beta2 / ppc64
In-Reply-To: <043.e34ebfca87896c1671e8c328f47fa932@varnish-cache.org>
References: <043.e34ebfca87896c1671e8c328f47fa932@varnish-cache.org>
Message-ID: <052.759793d9d0d60aa5d4fc8038ca545667@varnish-cache.org>

#756: tests/c00031.vtc fails on RHEL6 beta2 / ppc64
--------------------+-------------------------------------------------------
 Reporter:  ingvar  |       Owner:       
     Type:  defect  |      Status:  new  
 Priority:  normal  |   Milestone:       
Component:  build   |     Version:  2.1.3
 Severity:  normal  |    Keywords:       
--------------------+-------------------------------------------------------

Comment(by ingvar):

 changed version to 2.1.3.

-- 
Ticket URL: <http://varnish-cache.org/ticket/756#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Thu Aug 19 21:38:13 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Thu, 19 Aug 2010 21:38:13 -0000
Subject: [Varnish] #757: tests/c00031.vtc and tests/c00035.vtc fails on
	RHEL6 beta2 / ppc64
Message-ID: <043.1fe65b8fea39fb86bb41ce08de5f9861@varnish-cache.org>

#757: tests/c00031.vtc and tests/c00035.vtc fails on RHEL6 beta2 / ppc64
--------------------+-------------------------------------------------------
 Reporter:  ingvar  |       Owner:       
     Type:  defect  |      Status:  new  
 Priority:  normal  |   Milestone:       
Component:  build   |     Version:  trunk
 Severity:  normal  |    Keywords:       
--------------------+-------------------------------------------------------
 See ticket #756, but now also on trunk

 See attached output

-- 
Ticket URL: <http://varnish-cache.org/ticket/757>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Fri Aug 20 13:19:58 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 20 Aug 2010 13:19:58 -0000
Subject: [Varnish] #758: x-forwarded-for header concatenates for every restart
Message-ID: <045.a2a1f4302fdcbcc87241fe7afe2db0ef@varnish-cache.org>

#758: x-forwarded-for header concatenates for every restart
----------------------+-----------------------------------------------------
 Reporter:  bert-jan  |        Type:  defect
   Status:  new       |    Priority:  normal
Milestone:            |   Component:  build 
  Version:  2.1.3     |    Severity:  normal
 Keywords:            |  
----------------------+-----------------------------------------------------
 Every time a request is restarted to try a different backend server in a
 cluster, the x-forwarded-for header gets the client ip added to it, even
 if it's already there:

 1st try[[BR]]
 TxHeader     b X-Forwarded-For: 83.161.214.5

 1st restart[[BR]]
 TxHeader     b X-Forwarded-For: 83.161.214.5, 83.161.214.5

 2nd restart[[BR]]
 TxHeader     c X-Forwarded-For: 83.161.214.5, 83.161.214.5, 83.161.214.5

 3rd restart[[BR]]
 TxHeader     b X-Forwarded-For: 83.161.214.5, 83.161.214.5, 83.161.214.5,
 83.161.214.5

 Obviously something went very wrong for all servers to be broken (haven't
 figured that out yet because only one actually was for this specific
 request) but this struck me as odd.

-- 
Ticket URL: <http://varnish-cache.org/ticket/758>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Sat Aug 21 12:03:22 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Sat, 21 Aug 2010 12:03:22 -0000
Subject: [Varnish] #758: x-forwarded-for header concatenates for every
	restart
In-Reply-To: <045.a2a1f4302fdcbcc87241fe7afe2db0ef@varnish-cache.org>
References: <045.a2a1f4302fdcbcc87241fe7afe2db0ef@varnish-cache.org>
Message-ID: <054.055738cb54536f6e4bed7af9c040ca0b@varnish-cache.org>

#758: x-forwarded-for header concatenates for every restart
-----------------------+----------------------------------------------------
  Reporter:  bert-jan  |        Type:  defect
    Status:  closed    |    Priority:  normal
 Milestone:            |   Component:  build 
   Version:  2.1.3     |    Severity:  normal
Resolution:  fixed     |    Keywords:        
-----------------------+----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 (In [5113]) Don't mess with X-forwarded-for on restarts.

 Fixes: #758

-- 
Ticket URL: </ticket/758#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Sat Aug 21 13:32:10 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Sat, 21 Aug 2010 13:32:10 -0000
Subject: [Varnish] #754: CLI communication error after some time running
In-Reply-To: <044.547964d2ae8acba825f355bf9b0bb5fd@varnish-cache.org>
References: <044.547964d2ae8acba825f355bf9b0bb5fd@varnish-cache.org>
Message-ID: <053.dd57d79f97e6e221763b11a2289ddbb3@varnish-cache.org>

#754: CLI communication error after some time running
------------------------+---------------------------------------------------
  Reporter:  Estartu    |        Type:  defect
    Status:  closed     |    Priority:  normal
 Milestone:             |   Component:  build 
   Version:  trunk      |    Severity:  normal
Resolution:  duplicate  |    Keywords:  cli   
------------------------+---------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => duplicate


Comment:

 I have determined that this is a duplicate of #744, and will close this
 ticket, so we only have one to track.

 You typescript was very helpful, I think I have zen'ed out one way this
 could happen now.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/754#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Sat Aug 21 13:40:50 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Sat, 21 Aug 2010 13:40:50 -0000
Subject: [Varnish] #744: CLI repeats previous commands instead of
	executing the current one
In-Reply-To: <040.7bcbd34eff3803a79d8b768f5b7f9087@varnish-cache.org>
References: <040.7bcbd34eff3803a79d8b768f5b7f9087@varnish-cache.org>
Message-ID: <049.7979453bd546e56f19dd9b8c09807acb@varnish-cache.org>

#744: CLI repeats previous commands instead of executing the current one
----------------------+-----------------------------------------------------
 Reporter:  tgr       |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  2.1.2
 Severity:  major     |    Keywords:  cli  
----------------------+-----------------------------------------------------

Comment(by phk):

 Ticket #754 was closed as duplicate of this ticket, it has a very useful
 typesecript.

 I think I can see how this could happen, but have not determined what the
 correct fix is yet.

 First, the "help" command output consists of two parts:  the stuff
 generated in the manager and the output from the same request when sent to
 the child.  This gives the impression that client responses are mixed up
 when they actually are not.

 What I suppose happen, is that we send a CLI command to the child which it
 takes longer than the cli_timeout param to serve, so the manager abandons
 the attempt to receive the response and returns CLIS_COMM.

 Next time we send a CLI command to the child, the previously un-received
 response is first in the pipeline, and we get the behaviour seen in the
 #754 typescript.

 The clean and easily understandable solution is to always treat CLI errors
 from the child as fatal, and restart the child on all such failures.

 This is somewhat draconian, and certainly will teach people to set the
 cli_timeout properly.

 I have not found any reasonable alternatives.

 Input welcome, while I try to implement this fix.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/744#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Sat Aug 21 14:57:16 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Sat, 21 Aug 2010 14:57:16 -0000
Subject: [Varnish] #744: CLI repeats previous commands instead of
	executing the current one
In-Reply-To: <040.7bcbd34eff3803a79d8b768f5b7f9087@varnish-cache.org>
References: <040.7bcbd34eff3803a79d8b768f5b7f9087@varnish-cache.org>
Message-ID: <049.f39b1ae7442d24a078ba5b6658ccb42c@varnish-cache.org>

#744: CLI repeats previous commands instead of executing the current one
----------------------+-----------------------------------------------------
 Reporter:  tgr       |        Owner:  phk   
     Type:  defect    |       Status:  closed
 Priority:  normal    |    Milestone:        
Component:  varnishd  |      Version:  2.1.2 
 Severity:  major     |   Resolution:  fixed 
 Keywords:  cli       |  
----------------------+-----------------------------------------------------
Changes (by phk):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 (In [5116]) Whenever the CLI comms with the child process runs of the
 rails, we
 have to kill the child:  We cannot get the CLI pipes back in sync,
 even if the child process was just preoccupied with something for
 much longer than cli_timeout.

 Fixes: #744

-- 
Ticket URL: </ticket/744#comment:4>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Sat Aug 21 15:07:41 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Sat, 21 Aug 2010 15:07:41 -0000
Subject: [Varnish] #756: tests/c00031.vtc fails on RHEL6 beta2 / ppc64
In-Reply-To: <043.e34ebfca87896c1671e8c328f47fa932@varnish-cache.org>
References: <043.e34ebfca87896c1671e8c328f47fa932@varnish-cache.org>
Message-ID: <052.65919a65998da0637b75edb5f3cb54ac@varnish-cache.org>

#756: tests/c00031.vtc fails on RHEL6 beta2 / ppc64
--------------------+-------------------------------------------------------
 Reporter:  ingvar  |       Owner:       
     Type:  defect  |      Status:  new  
 Priority:  normal  |   Milestone:       
Component:  build   |     Version:  2.1.3
 Severity:  normal  |    Keywords:       
--------------------+-------------------------------------------------------

Comment(by phk):

 c00031.vtc tests setting the thread stack size to 128k.

 It is not obvious to me why 128k stack would not work on this platform,
 but in all likelyhood it just needs to be a bigger number because ppc
 stackframes can be huge.

 There is nothing for it but to try some larger values to see what the
 realistisk minimum is, that will provide valuable documentation input
 also.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/756#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Sat Aug 21 15:12:04 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Sat, 21 Aug 2010 15:12:04 -0000
Subject: [Varnish] #757: tests/c00035.vtc fails on RHEL6 beta2 / ppc64
	(was: tests/c00031.vtc and tests/c00035.vtc fails on RHEL6 beta2 /
	ppc64)
In-Reply-To: <043.1fe65b8fea39fb86bb41ce08de5f9861@varnish-cache.org>
References: <043.1fe65b8fea39fb86bb41ce08de5f9861@varnish-cache.org>
Message-ID: <052.9ce3af6597c4e1eb49d13fa3ca04d888@varnish-cache.org>

#757: tests/c00035.vtc fails on RHEL6 beta2 / ppc64
--------------------+-------------------------------------------------------
 Reporter:  ingvar  |       Owner:       
     Type:  defect  |      Status:  new  
 Priority:  normal  |   Milestone:       
Component:  build   |     Version:  trunk
 Severity:  normal  |    Keywords:       
--------------------+-------------------------------------------------------

Comment(by phk):

 For c00031.vtc, see #756, it is the same thing.

 With respect to  c00035.vtc I am not really sure what the trouble is, but
 you can try to extend the "delay 0.5" to something longer and see if that
 helps.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/757#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 23 04:16:31 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 23 Aug 2010 04:16:31 -0000
Subject: [Varnish] #759: Varnish child crashes, restarts often
Message-ID: <047.b42407dbfad4f9e4b40b9019ebe14371@varnish-cache.org>

#759: Varnish child crashes, restarts often
------------------------+---------------------------------------------------
 Reporter:  allan.jude  |       Owner:  phk                    
     Type:  defect      |      Status:  new                    
 Priority:  high        |   Milestone:  Varnish 2.1 release    
Component:  varnishd    |     Version:  2.1.3                  
 Severity:  normal      |    Keywords:  crash segfault signal11
------------------------+---------------------------------------------------
 Aug 22 17:05:08 Dallas kernel: pid 48465 (varnishd), uid 80: exited on
 signal 11
 Aug 22 17:05:08 Dallas varnishd[1038]: Child (49614) said Child starts
 Aug 22 17:05:08 Dallas varnishd[1038]: Child (49614) said managed to mmap
 1073741824 bytes of 1073741824

 Aug 22 17:51:13 Dallas kernel: pid 49614 (varnishd), uid 80: exited on
 signal 11
 Aug 22 17:51:13 Dallas varnishd[1038]: Child (50033) said Child starts
 Aug 22 17:51:13 Dallas varnishd[1038]: Child (50033) said managed to mmap
 1073741824 bytes of 1073741824

 Aug 22 19:54:38 Dallas kernel: pid 50116 (varnishd), uid 0: exited on
 signal 11
 Aug 22 19:54:38 Dallas varnishd[50115]: Child (51028) said Child starts
 Aug 22 19:54:38 Dallas varnishd[50115]: Child (51028) said managed to mmap
 1073741824 bytes of 1073741824


 Aug 22 21:47:16 Dallas kernel: pid 51028 (varnishd), uid 0: exited on
 signal 11 (core dumped)
 Aug 22 21:47:15 Dallas varnishd[50115]: Child (51028) not responding to
 ping, killing it.
 Aug 22 21:47:16 Dallas varnishd[50115]: Child (51929) said Child starts
 Aug 22 21:47:16 Dallas varnishd[50115]: Child (51929) said managed to mmap
 1073741824 bytes of 1073741824

 install is from ports, recompiled with debug and enabled
 kern.sugid_coredump to get a core dump

 backtrace attached

-- 
Ticket URL: <http://varnish-cache.org/ticket/759>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 23 04:38:35 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 23 Aug 2010 04:38:35 -0000
Subject: [Varnish] #759: Varnish child crashes, restarts often
In-Reply-To: <047.b42407dbfad4f9e4b40b9019ebe14371@varnish-cache.org>
References: <047.b42407dbfad4f9e4b40b9019ebe14371@varnish-cache.org>
Message-ID: <056.9a869594d358e75903c7bbca7f835a9c@varnish-cache.org>

#759: Varnish child crashes, restarts often
------------------------+---------------------------------------------------
 Reporter:  allan.jude  |       Owner:  phk                    
     Type:  defect      |      Status:  new                    
 Priority:  high        |   Milestone:  Varnish 2.1 release    
Component:  varnishd    |     Version:  2.1.3                  
 Severity:  normal      |    Keywords:  crash segfault signal11
------------------------+---------------------------------------------------

Comment(by allan.jude):

 Forgot to mention:

 FreeBSD 8.1 64bit
 Same issue on 4 different servers, 3 of which have 2gb of ram (using 1gb
 mmap), and other has 8gb and uses 5gb mmap

 varnishd -P /var/run/varnishd.pid -a ip1:80,ip2:80 -f
 /usr/local/etc/varnish/servername.vcl -s malloc,32m -s
 file,/usr/local/scaleengine/varnish_cache.bin,1G -u www -g www -T
 127.0.01:6082

-- 
Ticket URL: <http://varnish-cache.org/ticket/759#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 23 11:24:25 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 23 Aug 2010 11:24:25 -0000
Subject: [Varnish] #759: Varnish child crashes, restarts often
In-Reply-To: <047.b42407dbfad4f9e4b40b9019ebe14371@varnish-cache.org>
References: <047.b42407dbfad4f9e4b40b9019ebe14371@varnish-cache.org>
Message-ID: <056.0487da0a0b561c6218d3eb5b56ea2dc9@varnish-cache.org>

#759: Varnish child crashes, restarts often
------------------------+---------------------------------------------------
 Reporter:  allan.jude  |       Owner:  martin                 
     Type:  defect      |      Status:  new                    
 Priority:  high        |   Milestone:  Varnish 2.1 release    
Component:  varnishd    |     Version:  2.1.3                  
 Severity:  normal      |    Keywords:  crash segfault signal11
------------------------+---------------------------------------------------
Changes (by martin):

  * owner:  phk => martin


-- 
Ticket URL: <http://varnish-cache.org/ticket/759#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 23 11:25:17 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 23 Aug 2010 11:25:17 -0000
Subject: [Varnish] #745: Varnishstat
In-Reply-To: <049.d40e8595f1a7db9d87f52f66f6308e8a@varnish-cache.org>
References: <049.d40e8595f1a7db9d87f52f66f6308e8a@varnish-cache.org>
Message-ID: <058.d4b7d5d20d017afca682d0a564cd90db@varnish-cache.org>

#745: Varnishstat
--------------------------+-------------------------------------------------
 Reporter:  piripirigoso  |       Owner:  yves               
     Type:  defect        |      Status:  new                
 Priority:  high          |   Milestone:  Varnish 2.1 release
Component:  varnishstat   |     Version:  2.1.2              
 Severity:  critical      |    Keywords:  varnishstats       
--------------------------+-------------------------------------------------
Changes (by yves):

  * owner:  phk => yves


-- 
Ticket URL: <http://varnish-cache.org/ticket/745#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 23 11:25:35 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 23 Aug 2010 11:25:35 -0000
Subject: [Varnish] #745: Varnishstat
In-Reply-To: <049.d40e8595f1a7db9d87f52f66f6308e8a@varnish-cache.org>
References: <049.d40e8595f1a7db9d87f52f66f6308e8a@varnish-cache.org>
Message-ID: <058.0a67bce1cbc5e3bcbcea1d473a956575@varnish-cache.org>

#745: Varnishstat
--------------------------+-------------------------------------------------
 Reporter:  piripirigoso  |       Owner:  yves               
     Type:  defect        |      Status:  assigned           
 Priority:  high          |   Milestone:  Varnish 2.1 release
Component:  varnishstat   |     Version:  2.1.2              
 Severity:  critical      |    Keywords:  varnishstats       
--------------------------+-------------------------------------------------
Changes (by yves):

  * status:  new => assigned


-- 
Ticket URL: <http://varnish-cache.org/ticket/745#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 23 11:26:22 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 23 Aug 2010 11:26:22 -0000
Subject: [Varnish] #745: Varnishstat
In-Reply-To: <049.d40e8595f1a7db9d87f52f66f6308e8a@varnish-cache.org>
References: <049.d40e8595f1a7db9d87f52f66f6308e8a@varnish-cache.org>
Message-ID: <058.af3564b34bb86ad424396f76b0306c2a@varnish-cache.org>

#745: Varnishstat
--------------------------+-------------------------------------------------
 Reporter:  piripirigoso  |        Owner:  yves               
     Type:  defect        |       Status:  closed             
 Priority:  high          |    Milestone:  Varnish 2.1 release
Component:  varnishstat   |      Version:  2.1.2              
 Severity:  critical      |   Resolution:  invalid            
 Keywords:  varnishstats  |  
--------------------------+-------------------------------------------------
Changes (by yves):

  * status:  assigned => closed
  * resolution:  => invalid


Comment:

 Have not heard back from the reporter. Closing the case as of today.

-- 
Ticket URL: <http://varnish-cache.org/ticket/745#comment:4>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 23 11:52:41 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 23 Aug 2010 11:52:41 -0000
Subject: [Varnish] #748: sess_timeout incorrectly used for in-flight
	requests
In-Reply-To: <041.55fc5bfd6b2333f61d0fbce65a241ee2@varnish-cache.org>
References: <041.55fc5bfd6b2333f61d0fbce65a241ee2@varnish-cache.org>
Message-ID: <050.75bc876d02be3a06fbd40c77f1dd7a0c@varnish-cache.org>

#748: sess_timeout incorrectly used for in-flight requests
--------------------+-------------------------------------------------------
 Reporter:  xb95    |        Owner:  martin    
     Type:  defect  |       Status:  closed    
 Priority:  normal  |    Milestone:            
Component:  build   |      Version:  2.1.0     
 Severity:  minor   |   Resolution:  worksforme
 Keywords:          |  
--------------------+-------------------------------------------------------
Changes (by martin):

  * status:  new => closed
  * resolution:  => worksforme


Comment:

 Closing this with a Works-for-me resolution, as I am unable to reproduce
 your findings. Varnish correctly uses the first_byte_timeout and
 between_bytes_timeout for back end connections in all my tests.
 sess_timeout does not seem to have any influence on these connections.

-- 
Ticket URL: <http://varnish-cache.org/ticket/748#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 23 14:19:18 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 23 Aug 2010 14:19:18 -0000
Subject: [Varnish] #759: Varnish child crashes, restarts often
In-Reply-To: <047.b42407dbfad4f9e4b40b9019ebe14371@varnish-cache.org>
References: <047.b42407dbfad4f9e4b40b9019ebe14371@varnish-cache.org>
Message-ID: <056.b1c43cbb48ae20fc7850cae78a9c2e35@varnish-cache.org>

#759: Varnish child crashes, restarts often
------------------------+---------------------------------------------------
 Reporter:  allan.jude  |       Owner:  martin                 
     Type:  defect      |      Status:  new                    
 Priority:  high        |   Milestone:  Varnish 2.1 release    
Component:  varnishd    |     Version:  2.1.3                  
 Severity:  normal      |    Keywords:  crash segfault signal11
------------------------+---------------------------------------------------

Comment(by allan.jude):

 Aug 23 02:29:07 Dallas varnishd[64478]: Child (65670) not responding to
 ping, killing it.[[BR]]
 Aug 23 02:29:07 Dallas kernel: pid 65670 (varnishd), uid 80: exited on
 signal 6 (core dumped)[[BR]]
 Aug 23 02:29:07 Dallas varnishd[64478]: Child (65670) Panic message:
 Assert error in STV_alloc(), stevedore.c line 192:   Condition((st) !=
 NULL) not true. errno = 22 (Invalid argument) thread = (cache-worker)
 ident = FreeBSD,8.1-RELEASE,amd64,-smalloc,-sfile,-hcritbit,kqueue
 Backtrace:   0x429394: pan_ic+164   0x44446a: STV_alloc+22a   0x41e5e4:
 fetch_chunked+1d4   0x41f6c9: FetchBody+399   0x4157b2: cnt_fetch+cd2
 0x417c6b: CNT_Session+57b   0x42ae6a: wrk_do_cnt_sess+12a   0x42a706:
 wrk_thread_real+6e6   0x42aac2: wrk_thread+e2   0x800c2b511:
 _end+8006b0059 sp = 0x84746a008 {   fd = 219, id = 219, xid = 12598802,
 client = 218.186.10.14:17034,   step = STP_FETCH,   handling = pass,
 err_code = 200, err_reason = (null),   restarts = 0, esis = 0   ws =
 0x84746a078 {      id = "sess",     {s,f,r,e} =
 {0x84746acc0,+1120,0x0,+65536},   },   http[req] = {     ws =
 0x84746a078[sess]       "GET",       "/One-
 Piece/chapter-553/page005.html",       "HTTP/1.1",       "User-Agent:
 Mozilla/5.0 (Windows; U; Windows NT 6[[BR]]
 Aug 23 02:29:07 Dallas kernel: ows NT 6[[BR]]
 Aug 23 02:29:07 Dallas varnishd[64478]: child (66841) Started[[BR]]
 Aug 23 02:29:07 Dallas varnishd[64478]: Child (66841) said[[BR]]
 Aug 23 02:29:07 Dallas varnishd[64478]: Child (66841) said Child
 starts[[BR]]
 Aug 23 02:29:07 Dallas varnishd[64478]: Child (66841) said managed to mmap
 1073741824 bytes of 1073741824[[BR]]

 [[BR]][[BR]]

 Aug 23 06:38:52 Dallas kernel: pid 66841 (varnishd), uid 80: exited on
 signal 6 (core dumped)[[BR]]
 Aug 23 06:38:53 Dallas varnishd[64478]: Child (66841) Panic message:
 Assert error in STV_alloc(), stevedore.c line 192:   Condition((st) !=
 NULL) not true. errno = 22 (Invalid argument) thread = (cache-worker)
 ident = FreeBSD,8.1-RELEASE,amd64,-smalloc,-sfile,-hcritbit,kqueue
 Backtrace:   0x429394: pan_ic+164   0x44446a: STV_alloc+22a   0x41e5e4:
 fetch_chunked+1d4   0x41f6c9: FetchBody+399   0x4157b2: cnt_fetch+cd2
 0x417c6b: CNT_Session+57b   0x42ae6a: wrk_do_cnt_sess+12a   0x42a706:
 wrk_thread_real+6e6   0x42aac2: wrk_thread+e2   0x800c2b511:
 _end+8006b0059 sp = 0x846ee1008 {   fd = 65, id = 65, xid = 1649773165,
 client = 82.228.253.169:64307,   step = STP_FETCH,   handling = pass,
 err_code = 200, err_reason = (null),   restarts = 0, esis = 0   ws =
 0x846ee1078 {      id = "sess",     {s,f,r,e} =
 {0x846ee1cc0,+1360,0x0,+65536},   },   http[req] = {     ws =
 0x846ee1078[sess]       "GET",       "/Gantz/chapter-232/page003.html",
 "HTTP/1.1",       "User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac
 OS[[BR]]
 Aug 23 06:38:53 Dallas kernel: Mac OS[[BR]]
 Aug 23 06:38:53 Dallas varnishd[64478]: child (69194) Started[[BR]]
 Aug 23 06:38:53 Dallas varnishd[64478]: Child (69194) said[[BR]]
 Aug 23 06:38:53 Dallas varnishd[64478]: Child (69194) said Child
 starts[[BR]]
 Aug 23 06:38:53 Dallas varnishd[64478]: Child (69194) said managed to mmap
 1073741824 bytes of 1073741824[[BR]]


 [[BR]][[BR]]

 (gdb) bt [[BR]]
 #0  0x0000000800eaf03c in thr_kill () from /lib/libc.so.7 [[BR]]
 #1  0x0000000800f4b1cb in abort () from /lib/libc.so.7 [[BR]]
 #2  0x00000000004294d1 in pan_ic (func=Could not find the frame base for
 "pan_ic".
 ) at cache_panic.c:365 [[BR]]
 #3  0x000000000044446a in STV_alloc (sp=0x846ee1008, size=131072, oc=0x0)
     at stevedore.c:192 [[BR]]
 #4  0x000000000041e5e4 in fetch_chunked (sp=0x846ee1008,
 htc=0x7ffffd7ece48)
     at cache_fetch.c:167 [[BR]]
 #5  0x000000000041f6c9 in FetchBody (sp=0x846ee1008) at cache_fetch.c:461
 [[BR]]
 #6  0x00000000004157b2 in cnt_fetch (sp=0x846ee1008) at cache_center.c:594
 [[BR]]
 #7  0x0000000000417c6b in CNT_Session (sp=0x846ee1008) at steps.h:41
 [[BR]]
 #8  0x000000000042ae6a in wrk_do_cnt_sess (w=0x7ffffd7ecd30,
 priv=0x846ee1008)
     at cache_pool.c:294 [[BR]]
 #9  0x000000000042a706 in wrk_thread_real (qp=0x801213420,
 shm_workspace=8192,
     sess_workspace=65536, nhttp=64, http_space=1160, siov=128)
     at cache_pool.c:183 [[BR]]
 #10 0x000000000042aac2 in wrk_thread (priv=0x801213420) at
 cache_pool.c:224 [[BR]]
 #11 0x0000000800c2b511 in pthread_getprio () from /lib/libthr.so.3 [[BR]]
 #12 0x00007ffffd5ed000 in ?? () [[BR]]
 Cannot access memory at address 0x7ffffd7ed000 [[BR]]

-- 
Ticket URL: <http://varnish-cache.org/ticket/759#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 23 14:26:59 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 23 Aug 2010 14:26:59 -0000
Subject: [Varnish] #759: Varnish child crashes, restarts often
In-Reply-To: <047.b42407dbfad4f9e4b40b9019ebe14371@varnish-cache.org>
References: <047.b42407dbfad4f9e4b40b9019ebe14371@varnish-cache.org>
Message-ID: <056.ec481fe17cd9ccd30dfbc5c7f0eb1f80@varnish-cache.org>

#759: Varnish child crashes, restarts often
------------------------+---------------------------------------------------
 Reporter:  allan.jude  |       Owner:  martin                 
     Type:  defect      |      Status:  new                    
 Priority:  high        |   Milestone:  Varnish 2.1 release    
Component:  varnishd    |     Version:  2.1.3                  
 Severity:  normal      |    Keywords:  crash segfault signal11
------------------------+---------------------------------------------------

Comment(by allan.jude):

 Should the core dumps be bigger? they are almost 300mb on average, but
 varnish is set for 1gb plus all the structures etc:[[BR]]

 PID USERNAME   THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
 [[BR]]
 69194 www         69  44    0  1302M  1217M ucond   1   1:58  0.10%
 varnishd [[BR]]

 -rw-------  1 www   www   289M Aug 23 00:01 core1.core [[BR]]
 -rw-------  1 www   www   287M Aug 23 02:29 core2.core [[BR]]
 -rw-------  1 www   www   270M Aug 23 06:38 core3.core [[BR]]

-- 
Ticket URL: <http://varnish-cache.org/ticket/759#comment:4>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 23 14:56:18 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 23 Aug 2010 14:56:18 -0000
Subject: [Varnish] #760: varnishlog unbuffered output
Message-ID: <045.bbcca487396d337b069b2c55e4ee6665@varnish-cache.org>

#760: varnishlog unbuffered output
------------------------+---------------------------------------------------
 Reporter:  blade106    |       Owner:  phk              
     Type:  defect      |      Status:  new              
 Priority:  normal      |   Milestone:                   
Component:  varnishlog  |     Version:  2.1.3            
 Severity:  normal      |    Keywords:  varnishlog output
------------------------+---------------------------------------------------
 In varnishlog, there's an option ?-u? to set the output unbuffered. But
 this option can't be used if the ?-o? (Group log entries by request ID) is
 used. This can be fixed by inverting the two options in the varnishlog.c.

 Current code (near line 387):
 {{{
         if (o_flag)
                 do_order(vd, argc - optind, argv + optind);

         if (u_flag)
                 setbuf(stdout, NULL);
 }}}

 New working code:
 {{{
         if (u_flag)
                 setbuf(stdout, NULL);

         if (o_flag)
                 do_order(vd, argc - optind, argv + optind);
 }}}

 As I'm not a C coder, I don't know if there's any issue inverting these,
 but for the 4 past months I've used it and nothing went wrong.

-- 
Ticket URL: <http://varnish-cache.org/ticket/760>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 23 16:06:05 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 23 Aug 2010 16:06:05 -0000
Subject: [Varnish] #759: Varnish child crashes, restarts often
In-Reply-To: <047.b42407dbfad4f9e4b40b9019ebe14371@varnish-cache.org>
References: <047.b42407dbfad4f9e4b40b9019ebe14371@varnish-cache.org>
Message-ID: <056.723c7c04376e66da36dc1509238d6250@varnish-cache.org>

#759: Varnish child crashes, restarts often
------------------------+---------------------------------------------------
 Reporter:  allan.jude  |       Owner:  martin                 
     Type:  defect      |      Status:  new                    
 Priority:  high        |   Milestone:  Varnish 2.1 release    
Component:  varnishd    |     Version:  2.1.3                  
 Severity:  normal      |    Keywords:  crash segfault signal11
------------------------+---------------------------------------------------

Comment(by allan.jude):

 I tried rebooting the server again, didn't help
  [[BR]]
 Aug 23 11:41:44 Dallas kernel: pid 2260 (varnishd), uid 80: exited on
 signal 6 [[BR]]
 Aug 23 15:41:44 Dallas varnishd[1037]: Child (2260) Panic message: Assert
 error in STV_alloc(), stevedore.c line 192:   Condition((st) != NULL) not
 true. errno = 22 (Invalid argument) thread = (cache-worker) ident =
 FreeBSD,8.1-RELEASE,amd64,-smalloc,-sfile,-hcritbit,kqueue Backtrace:
 0x429394: pan_ic+164   0x44446a: STV_alloc+22a   0x41e2c6:
 fetch_straight+96   0x41f67a: FetchBody+34a   0x4157b2: cnt_fetch+cd2
 0x417c6b: CNT_Session+57b   0x42ae6a: wrk_do_cnt_sess+12a   0x42a706:
 wrk_thread_real+6e6   0x42aac2: wrk_thread+e2   0x800c2b511:
 _end+8006b0059 sp = 0x8477be008 {   fd = 17, id = 17, xid = 812957110,
 client = 217.157.186.32:28064,   step = STP_FETCH,   handling = deliver,
 err_code = 200, err_reason = (null),   restarts = 0, esis = 0   ws =
 0x8477be078 {      id = "sess",     {s,f,r,e} =
 {0x8477becc0,+848,0x0,+65536},   },   http[req] = {     ws =
 0x8477be078[sess]       "GET",       "/manga/One-Piece/562/002.jpg",
 "HTTP/1.1",       "User-Agent: Mozilla/5.0 (iPad; U; CPU OS 3_2_1 like Mac
 [[BR]]
 Aug 23 11:41:44 Dallas kernel: ike Mac [[BR]]
 Aug 23 15:41:44 Dallas varnishd[1037]: child (2275) Started [[BR]]
 Aug 23 15:41:44 Dallas varnishd[1037]: Child (2275) said [[BR]]
 Aug 23 15:41:44 Dallas varnishd[1037]: Child (2275) said Child starts
 [[BR]]
 Aug 23 15:41:44 Dallas varnishd[1037]: Child (2275) said managed to mmap
 1073741824 bytes of 1073741824 [[BR]]

-- 
Ticket URL: <http://varnish-cache.org/ticket/759#comment:5>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 23 16:56:52 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 23 Aug 2010 16:56:52 -0000
Subject: [Varnish] #761: critbit segfault
Message-ID: <040.60f07b58d2dfaf8df27b4a4d77300498@varnish-cache.org>

#761: critbit segfault
----------------------+-----------------------------------------------------
 Reporter:  sky       |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  2.1.3
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
 Panic message: Assert error in hcb_lookup(), hash_critbit.c line 475:
 Condition(!with_lock) not true. thread = (cache-worker) ident =
 Linux,2.6.32-24-server,x86_64,-sfile,-sfile,-sfile,-sfile,-sfile,-sfile,-hcritbit,epoll
 Backtrace: ??0x424878: /usr/sbin/varnishd() [0x424878] ??0x43182d:
 /usr/sbin/varnishd() [0x43182d] ??0x41e8e9:
 /usr/sbin/varnishd(HSH_Lookup+0x6a9) [0x41e8e9] ??0x412dab:
 /usr/sbin/varnishd() [0x412dab] ??0x4152fd:
 /usr/sbin/varnishd(CNT_Session+0x38d) [0x4152fd] ??0x426028:
 /usr/sbin/varnishd() [0x426028] ??0x4263fb: /usr/sbin/varnishd()
 [0x4263fb] ??0x7f31aeaff9ca: /lib/libpthread.so.0(+0x69ca)
 [0x7f31aeaff9ca] ??0x7f31ae3bf6fd: /lib/libc.so.6(clone+0x6d)
 [0x7f31ae3bf6fd] sp = 0x7e736c402008 { ??fd = 3453, id = 3453, xid =
 1257538524, ??client = 74.79.40.95:58308, ??step = STP_LOOKUP, ??handling
 = hash, ??err_code = 503, err_reason = (null), ??restarts = 0, esis = 0
 ws = 0x7e736c402078 { ?????id = "sess", ????{s,f,r,e} =
 {0x7e736c402cd0,+3328,(nil),+131072}, ??}, ??http[req] = { ????ws =
 0x7e736c402078[sess] ??????"GET",
 "/extensions/wikia/StaticChute/?type=css&packages=monaco_css_print&checksum=75a075dd32dd6479a937ee61cbd5940f",
 "HTTP/1.1", ??????"User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X
 10_6_4; en-us) AppleWebKit/533.17.8 (KHTML, like Gecko) Version/5.0.1
 Safari/533.17.8", ??????"Accept: text/css,*/*;q=0.1", ??????"Referer:
 http://www.wowwiki.com/Portal:Main", ??????"Accept-Language: en-us",
 "Connection: keep-alive", ??????"X-Forwarded-From: varnish-i7-IOWA",
 "X-Forwarded-For: 74.79.40.95", ??????"Accept-Encoding: gzip",
 "host: www.wowwiki.com", ??????????"X-Logged-In: 0", ??}, ??worker =
 0x7e7651478be0 { ????ws = 0x7e7651478d50 { ???????id = "wrk",
 {s,f,r,e} = {0x7e7651450b80,0x7e7651450b80,(nil),+131072}, ????}, ????},
 vcl = { ??????srcname = { ????????"input", ????????"Default",
 "/etc/varnish/yellowiki.vcl", ????????"/etc/varnish/SJC_backends.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/IOWA_backends.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl", ????????"/etc/varnish/routing.vcl",
 "/etc/varnish/wiki-stats.vcl", ????????"/etc/varnish/misc.vcl",
 "/etc/varnish/liftium_edge.vcl",
 "/etc/varnish/external_healthchecks.vcl",
 "/etc/varnish/riak_backends.vcl",
 "/etc/varnish/riak_healthcheck.vcl",
 "/etc/varnish/riak_healthcheck.vcl",
 "/etc/varnish/riak_healthcheck.vcl",
 "/etc/varnish/riak_healthcheck.vcl",
 "/etc/varnish/spotlights_edge.vcl", ????????"/etc/varnish/dev-
 backend.vcl", ????????"/etc/varnish/image

-- 
Ticket URL: <http://varnish-cache.org/ticket/761>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Aug 24 11:41:52 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 24 Aug 2010 11:41:52 -0000
Subject: [Varnish] #756: tests/c00031.vtc fails on RHEL6 beta2 / ppc64
In-Reply-To: <043.e34ebfca87896c1671e8c328f47fa932@varnish-cache.org>
References: <043.e34ebfca87896c1671e8c328f47fa932@varnish-cache.org>
Message-ID: <052.6503516547c238decc0958661042995d@varnish-cache.org>

#756: tests/c00031.vtc fails on RHEL6 beta2 / ppc64
--------------------+-------------------------------------------------------
 Reporter:  ingvar  |       Owner:       
     Type:  defect  |      Status:  new  
 Priority:  normal  |   Milestone:       
Component:  build   |     Version:  2.1.3
 Severity:  normal  |    Keywords:       
--------------------+-------------------------------------------------------

Comment(by ingvar):

 256k seems to work, at least it runs the test without failing. I will just
 make an arch specific patch for this in the rpm package for now, but it
 would have been better to make this a setting that would work
 automatically by configure or whatnot.

 I have now access to a working rhel6/ppc64 environment, and can do
 debugging work if necessary.

 Ingvar

-- 
Ticket URL: <http://varnish-cache.org/ticket/756#comment:4>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Aug 24 14:47:03 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 24 Aug 2010 14:47:03 -0000
Subject: [Varnish] #757: tests/c00035.vtc fails on RHEL6 beta2 / ppc64
In-Reply-To: <043.1fe65b8fea39fb86bb41ce08de5f9861@varnish-cache.org>
References: <043.1fe65b8fea39fb86bb41ce08de5f9861@varnish-cache.org>
Message-ID: <052.a70ac908c8652df23eb71118e8d14543@varnish-cache.org>

#757: tests/c00035.vtc fails on RHEL6 beta2 / ppc64
-------------------------+--------------------------------------------------
 Reporter:  ingvar       |       Owner:  phk  
     Type:  defect       |      Status:  new  
 Priority:  normal       |   Milestone:       
Component:  varnishtest  |     Version:  trunk
 Severity:  normal       |    Keywords:       
-------------------------+--------------------------------------------------
Changes (by ingvar):

  * owner:  => phk
  * component:  build => varnishtest


Comment:

 Adding the delay to 1 second makes the test run without errors. Could this
 just be added to trunk, please?

 Ingvar

-- 
Ticket URL: <http://varnish-cache.org/ticket/757#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Aug 24 18:25:05 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 24 Aug 2010 18:25:05 -0000
Subject: [Varnish] #762: varnishstat segfault
Message-ID: <044.faeba9b0cd4de3f6b34ab7116b045a3d@varnish-cache.org>

#762: varnishstat segfault
---------------------+------------------------------------------------------
 Reporter:  victori  |        Type:  defect
   Status:  new      |    Priority:  normal
Milestone:           |   Component:  build 
  Version:  trunk    |    Severity:  normal
 Keywords:           |  
---------------------+------------------------------------------------------
 This is against trunk 5116M on opensolaris snv98.

 Running varnishstat returns a segfault unless I explicitly specify the
 hostname. Varnish 2.1.3 does not exhibit this issue.


 To sum it up, "varnishstat -n web" works fine while just "varnishstat"
 segfaults.

 {{{
 # truss varnishstat
 execve("/opt/extra/bin/varnishstat", 0xFFFFFD7FFFDFFC68,
 0xFFFFFD7FFFDFFC78)  argc = 1
 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
 MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF3A0000
 resolvepath("/usr/lib/amd64/ld.so.1", "/lib/amd64/ld.so.1", 1023) = 18
 resolvepath("/opt/extra/bin/varnishstat", "/opt/extra/bin/varnishstat",
 1023) = 26
 stat("/opt/extra/bin/varnishstat", 0xFFFFFD7FFFDFF840) = 0
 open("/var/ld/64/ld.config", O_RDONLY)          Err#2 ENOENT
 stat("/opt/extra/lib/libvarnishcompat.so.1", 0xFFFFFD7FFFDFED90) = 0
 resolvepath("/opt/extra/lib/libvarnishcompat.so.1",
 "/opt/extra/lib/libvarnishcompat.so.1.0.0", 1023) = 40
 open("/opt/extra/lib/libvarnishcompat.so.1", O_RDONLY) = 3
 mmap(0x00010000, 32768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_ALIGN, 3, 0)
 = 0xFFFFFD7FFF390000
 mmap(0x00010000, 73728, PROT_NONE,
 MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, 4294967295, 0) =
 0xFFFFFD7FFF370000
 mmap(0xFFFFFD7FFF370000, 5206, PROT_READ|PROT_EXEC,
 MAP_PRIVATE|MAP_FIXED|MAP_TEXT, 3, 0) = 0xFFFFFD7FFF370000
 mmap(0xFFFFFD7FFF381000, 2080, PROT_READ|PROT_WRITE,
 MAP_PRIVATE|MAP_FIXED|MAP_INITDATA, 3, 4096) = 0xFFFFFD7FFF381000
 munmap(0xFFFFFD7FFF372000, 61440)               = 0
 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
 MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF360000
 memcntl(0xFFFFFD7FFF370000, 3968, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
 close(3)                                        = 0
 stat("/opt/extra/lib/libvarnishapi.so.1", 0xFFFFFD7FFFDFED90) = 0
 resolvepath("/opt/extra/lib/libvarnishapi.so.1",
 "/opt/extra/lib/libvarnishapi.so.1.0.0", 1023) = 37
 open("/opt/extra/lib/libvarnishapi.so.1", O_RDONLY) = 3
 mmap(0xFFFFFD7FFF390000, 32768, PROT_READ|PROT_EXEC,
 MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFFFFFD7FFF390000
 mmap(0x00010000, 126976, PROT_NONE,
 MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, 4294967295, 0) =
 0xFFFFFD7FFF340000
 mmap(0xFFFFFD7FFF340000, 53584, PROT_READ|PROT_EXEC,
 MAP_PRIVATE|MAP_FIXED|MAP_TEXT, 3, 0) = 0xFFFFFD7FFF340000
 mmap(0xFFFFFD7FFF35D000, 3840, PROT_READ|PROT_WRITE,
 MAP_PRIVATE|MAP_FIXED|MAP_INITDATA, 3, 53248) = 0xFFFFFD7FFF35D000
 mmap(0xFFFFFD7FFF35E000, 160, PROT_READ|PROT_WRITE,
 MAP_PRIVATE|MAP_FIXED|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF35E000
 munmap(0xFFFFFD7FFF34E000, 61440)               = 0
 memcntl(0xFFFFFD7FFF340000, 12368, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
 close(3)                                        = 0
 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
 MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF330000
 stat("/opt/extra/lib/libumem.so.1", 0xFFFFFD7FFFDFED90) Err#2 ENOENT
 stat("/opt/extra/lib/amd64/libumem.so.1", 0xFFFFFD7FFFDFED90) Err#2 ENOENT
 stat("/opt/sfw/lib/amd64/libumem.so.1", 0xFFFFFD7FFFDFED90) Err#2 ENOENT
 stat("/lib/64/libumem.so.1", 0xFFFFFD7FFFDFED90) = 0
 resolvepath("/lib/64/libumem.so.1", "/lib/amd64/libumem.so.1", 1023) = 23
 open("/lib/64/libumem.so.1", O_RDONLY)          = 3
 mmap(0xFFFFFD7FFF390000, 32768, PROT_READ|PROT_EXEC,
 MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFFFFFD7FFF390000
 mmap(0x00010000, 290816, PROT_NONE,
 MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, 4294967295, 0) =
 0xFFFFFD7FFF2E0000
 mmap(0xFFFFFD7FFF2E0000, 147325, PROT_READ|PROT_EXEC,
 MAP_PRIVATE|MAP_FIXED|MAP_TEXT, 3, 0) = 0xFFFFFD7FFF2E0000
 mmap(0xFFFFFD7FFF314000, 30202, PROT_READ|PROT_WRITE,
 MAP_PRIVATE|MAP_FIXED|MAP_INITDATA, 3, 147456) = 0xFFFFFD7FFF314000
 mmap(0xFFFFFD7FFF31C000, 43296, PROT_READ|PROT_WRITE,
 MAP_PRIVATE|MAP_FIXED|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF31C000
 munmap(0xFFFFFD7FFF304000, 65536)               = 0
 memcntl(0xFFFFFD7FFF2E0000, 75576, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
 close(3)                                        = 0
 stat("/opt/extra/lib/libpcre.so.0", 0xFFFFFD7FFFDFED90) = 0
 resolvepath("/opt/extra/lib/libpcre.so.0",
 "/opt/extra/lib/libpcre.so.0.0.1", 1023) = 31
 open("/opt/extra/lib/libpcre.so.0", O_RDONLY)   = 3
 mmap(0xFFFFFD7FFF390000, 32768, PROT_READ|PROT_EXEC,
 MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFFFFFD7FFF390000
 close(3)                                        = 0
 stat("/opt/extra/lib/amd64/libpcre.so.0", 0xFFFFFD7FFFDFED90) = 0
 resolvepath("/opt/extra/lib/amd64/libpcre.so.0",
 "/opt/extra/lib/amd64/libpcre.so.0.0.1", 1023) = 37
 open("/opt/extra/lib/amd64/libpcre.so.0", O_RDONLY) = 3
 mmap(0xFFFFFD7FFF390000, 32768, PROT_READ|PROT_EXEC,
 MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFFFFFD7FFF390000
 mmap(0x00010000, 212992, PROT_NONE,
 MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, 4294967295, 0) =
 0xFFFFFD7FFF2A0000
 mmap(0xFFFFFD7FFF2A0000, 143200, PROT_READ|PROT_EXEC,
 MAP_PRIVATE|MAP_FIXED|MAP_TEXT, 3, 0) = 0xFFFFFD7FFF2A0000
 mmap(0xFFFFFD7FFF2D2000, 5240, PROT_READ|PROT_WRITE,
 MAP_PRIVATE|MAP_FIXED|MAP_INITDATA, 3, 139264) = 0xFFFFFD7FFF2D2000
 munmap(0xFFFFFD7FFF2C3000, 61440)               = 0
 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
 MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF290000
 memcntl(0xFFFFFD7FFF2A0000, 10632, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
 close(3)                                        = 0
 stat("/opt/extra/lib/libcurses.so.1", 0xFFFFFD7FFFDFED90) Err#2 ENOENT
 stat("/opt/extra/lib/amd64/libcurses.so.1", 0xFFFFFD7FFFDFED90) Err#2
 ENOENT
 stat("/opt/sfw/lib/amd64/libcurses.so.1", 0xFFFFFD7FFFDFED90) Err#2 ENOENT
 stat("/lib/64/libcurses.so.1", 0xFFFFFD7FFFDFED90) = 0
 resolvepath("/lib/64/libcurses.so.1", "/lib/amd64/libcurses.so.1", 1023) =
 25
 open("/lib/64/libcurses.so.1", O_RDONLY)        = 3
 mmap(0xFFFFFD7FFF390000, 32768, PROT_READ|PROT_EXEC,
 MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFFFFFD7FFF390000
 mmap(0x00010000, 372736, PROT_NONE,
 MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, 4294967295, 0) =
 0xFFFFFD7FFF230000
 mmap(0xFFFFFD7FFF230000, 251310, PROT_READ|PROT_EXEC,
 MAP_PRIVATE|MAP_FIXED|MAP_TEXT, 3, 0) = 0xFFFFFD7FFF230000
 mmap(0xFFFFFD7FFF27E000, 38067, PROT_READ|PROT_WRITE,
 MAP_PRIVATE|MAP_FIXED|MAP_INITDATA, 3, 253952) = 0xFFFFFD7FFF27E000
 mmap(0xFFFFFD7FFF288000, 10448, PROT_READ|PROT_WRITE,
 MAP_PRIVATE|MAP_FIXED|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF288000
 munmap(0xFFFFFD7FFF26E000, 65536)               = 0
 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
 MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF220000
 memcntl(0xFFFFFD7FFF230000, 132160, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
 close(3)                                        = 0
 stat("/opt/extra/lib/librt.so.1", 0xFFFFFD7FFFDFED90) Err#2 ENOENT
 stat("/opt/extra/lib/amd64/librt.so.1", 0xFFFFFD7FFFDFED90) Err#2 ENOENT
 stat("/opt/sfw/lib/amd64/librt.so.1", 0xFFFFFD7FFFDFED90) Err#2 ENOENT
 stat("/lib/64/librt.so.1", 0xFFFFFD7FFFDFED90)  = 0
 resolvepath("/lib/64/librt.so.1", "/lib/amd64/librt.so.1", 1023) = 21
 open("/lib/64/librt.so.1", O_RDONLY)            = 3
 mmap(0xFFFFFD7FFF390000, 32768, PROT_READ|PROT_EXEC,
 MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFFFFFD7FFF390000
 munmap(0xFFFFFD7FFF392000, 24576)               = 0
 close(3)                                        = 0
 stat("/opt/extra/lib/libpthread.so.1", 0xFFFFFD7FFFDFED90) Err#2 ENOENT
 stat("/opt/extra/lib/amd64/libpthread.so.1", 0xFFFFFD7FFFDFED90) Err#2
 ENOENT
 stat("/opt/sfw/lib/amd64/libpthread.so.1", 0xFFFFFD7FFFDFED90) Err#2
 ENOENT
 stat("/lib/64/libpthread.so.1", 0xFFFFFD7FFFDFED90) = 0
 resolvepath("/lib/64/libpthread.so.1", "/lib/amd64/libpthread.so.1", 1023)
 = 26
 open("/lib/64/libpthread.so.1", O_RDONLY)       = 3
 mmap(0x00010000, 32768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_ALIGN, 3, 0)
 = 0xFFFFFD7FFF210000
 munmap(0xFFFFFD7FFF213000, 20480)               = 0
 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
 MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF200000
 close(3)                                        = 0
 stat("/opt/extra/lib/libc.so.1", 0xFFFFFD7FFFDFED90) Err#2 ENOENT
 stat("/opt/extra/lib/amd64/libc.so.1", 0xFFFFFD7FFFDFED90) Err#2 ENOENT
 stat("/opt/sfw/lib/amd64/libc.so.1", 0xFFFFFD7FFFDFED90) Err#2 ENOENT
 stat("/lib/64/libc.so.1", 0xFFFFFD7FFFDFED90)   = 0
 resolvepath("/lib/64/libc.so.1", "/lib/amd64/libc.so.1", 1023) = 20
 open("/lib/64/libc.so.1", O_RDONLY)             = 3
 mmap(0x00010000, 32768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_ALIGN, 3, 0)
 = 0xFFFFFD7FFF1F0000
 mmap(0x00010000, 1708032, PROT_NONE,
 MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, 4294967295, 0) =
 0xFFFFFD7FFF040000
 mmap(0xFFFFFD7FFF040000, 1582665, PROT_READ|PROT_EXEC,
 MAP_PRIVATE|MAP_FIXED|MAP_TEXT, 3, 0) = 0xFFFFFD7FFF040000
 mmap(0xFFFFFD7FFF1D3000, 45970, PROT_READ|PROT_WRITE,
 MAP_PRIVATE|MAP_FIXED|MAP_INITDATA, 3, 1585152) = 0xFFFFFD7FFF1D3000
 mmap(0xFFFFFD7FFF1DF000, 5144, PROT_READ|PROT_WRITE,
 MAP_PRIVATE|MAP_FIXED|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF1DF000
 munmap(0xFFFFFD7FFF1C3000, 65536)               = 0
 memcntl(0xFFFFFD7FFF040000, 459400, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
 close(3)                                        = 0
 stat("/opt/extra/lib/libgcc_s.so.1", 0xFFFFFD7FFFDFED90) Err#2 ENOENT
 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
 MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF030000
 stat("/opt/sfw/lib/amd64/libgcc_s.so.1", 0xFFFFFD7FFFDFED90) = 0
 resolvepath("/opt/sfw/lib/amd64/libgcc_s.so.1",
 "/opt/sfw/lib/amd64/libgcc_s.so.1", 1023) = 32
 open("/opt/sfw/lib/amd64/libgcc_s.so.1", O_RDONLY) = 3
 mmap(0xFFFFFD7FFF1F0000, 32768, PROT_READ|PROT_EXEC,
 MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFFFFFD7FFF1F0000
 mmap(0x00010000, 126976, PROT_NONE,
 MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, 4294967295, 0) =
 0xFFFFFD7FFF010000
 mmap(0xFFFFFD7FFF010000, 59200, PROT_READ|PROT_EXEC,
 MAP_PRIVATE|MAP_FIXED|MAP_TEXT, 3, 0) = 0xFFFFFD7FFF010000
 mmap(0xFFFFFD7FFF02E000, 3184, PROT_READ|PROT_WRITE,
 MAP_PRIVATE|MAP_FIXED|MAP_INITDATA, 3, 57344) = 0xFFFFFD7FFF02E000
 munmap(0xFFFFFD7FFF01F000, 61440)               = 0
 memcntl(0xFFFFFD7FFF010000, 20984, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
 close(3)                                        = 0
 stat("/opt/extra/lib/amd64/libgcc_s.so.1", 0xFFFFFD7FFFDFED90) Err#2
 ENOENT
 stat("/lib/64/libgcc_s.so.1", 0xFFFFFD7FFFDFED90) = 0
 resolvepath("/lib/64/libgcc_s.so.1", "/opt/sfw/lib/amd64/libgcc_s.so.1",
 1023) = 32
 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
 MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFF000000
 mmap(0x00010000, 24576, PROT_READ|PROT_WRITE|PROT_EXEC,
 MAP_PRIVATE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFFFFFD7FFEFF0000
 munmap(0xFFFFFD7FFF1F0000, 32768)               = 0
 getcontext(0xFFFFFD7FFFDFF450)
 mmap(0x00010000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC,
 MAP_PRIVATE|MAP_ANON|MAP_ALIGN, 4294967295, 0) = 0xFFFFFD7FFEFD0000
 getrlimit(RLIMIT_STACK, 0xFFFFFD7FFFDFF7B0)     = 0
 getpid()                                        = 8902 [8901]
 lwp_private(0, 0, 0xFFFFFD7FFEFD0200)           = 0x00000000
 setustack(0xFFFFFD7FFEFD02A8)
 sysconfig(_CONFIG_PAGESIZE)                     = 4096
 sysconfig(_CONFIG_STACK_PROT)                   = 3
 sysi86(SI86FPSTART, 0xFFFFFD7FFFDFFC1C, 0x0000133F, 0x00001F80) =
 0x00000001
 mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
 MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFFFD7FFEFC0000
 sysconfig(_CONFIG_NPROC_ONLN)                   = 4
 issetugid()                                     = 0
 issetugid()                                     = 0
 brk(0x00425000)                                 = 0
 brk(0x00435000)                                 = 0
 brk(0x00445000)                                 = 0
 open(0x00000000, O_RDONLY)                      Err#14 EFAULT
 fstat(2, 0xFFFFFD7FFFDEE7F0)                    = 0
 Cannot open write(2, " C a n n o t   o p e n  ", 12)    = 12
     Incurred fault #6, FLTBOUNDS  %pc = 0xFFFFFD7FFF0B94B0
       siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
     Received signal #11, SIGSEGV [default]
       siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000

 }}}

-- 
Ticket URL: <http://varnish-cache.org/ticket/762>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Aug 24 19:33:14 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 24 Aug 2010 19:33:14 -0000
Subject: [Varnish] #762: varnishstat segfault
In-Reply-To: <044.faeba9b0cd4de3f6b34ab7116b045a3d@varnish-cache.org>
References: <044.faeba9b0cd4de3f6b34ab7116b045a3d@varnish-cache.org>
Message-ID: <053.76e85d2f14032b7a39158eed00962572@varnish-cache.org>

#762: varnishstat segfault
---------------------+------------------------------------------------------
 Reporter:  victori  |        Type:  defect
   Status:  new      |    Priority:  normal
Milestone:           |   Component:  build 
  Version:  trunk    |    Severity:  normal
 Keywords:           |  
---------------------+------------------------------------------------------

Comment(by victori):

 dbx backtrace

 {{{
 (dbx) run
 Running: varnishstat
 (process id 14359)
 Cannot open t at 1 (l at 1) signal SEGV (no mapping at the fault address) in
 strlen at 0xfffffd7fff0b94b0
 0xfffffd7fff0b94b0: strlen+0x0040:      movq     (%rsi),%rax
 (dbx) where
 current thread: t at 1
 =>[1] strlen(0x0, 0x0, 0x0, 0x0, 0x0, 0x53), at 0xfffffd7fff0b94b0
   [2] _ndoprnt(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff0fcb1e
   [3] fprintf(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff0ff852
   [4] vsm_open(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff3453d0
   [5] main(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x40244d
 }}}


 gdb backtrace

 {{{
 (gdb) run
 Starting program: /opt/extra/bin/varnishstat
 Warning:
 Cannot insert breakpoint -2.
 Error accessing memory address 0xd276: I/O error.

 (gdb) bt
 #0  0x0000000000000000 in ?? ()
 Cannot access memory at address 0x0
 (gdb) backtrace
 #0  0x0000000000000000 in ?? ()
 Cannot access memory at address 0x0

 }}}

-- 
Ticket URL: <http://varnish-cache.org/ticket/762#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug 25 02:37:42 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 25 Aug 2010 02:37:42 -0000
Subject: [Varnish] #763: problem with invalid Headers
Message-ID: <050.7fd2b5e740c9a9cd98d2c557a6da5890@varnish-cache.org>

#763: problem with invalid Headers
---------------------------+------------------------------------------------
 Reporter:  danielpicolli  |       Owner:  phk                
     Type:  defect         |      Status:  new                
 Priority:  high           |   Milestone:  Varnish 2.1 release
Component:  varnishd       |     Version:  trunk              
 Severity:  major          |    Keywords:                     
---------------------------+------------------------------------------------
 hello!

 I found a little mistake in on cache_vary.c that caused a huge crash on
 varnish. We have 10 dual quad-core servers using varnish with about 14
 backends, one of these backends has been configured with wrong Vary
 header, something like " Vary:: Accept-Encoding", yes, with two ":",
 someone set it wrong and all of the varnish servers crashed. :-)

 The problem can be reproduced with nginx as backend:

 add_header Vary: Accept-Encoding;

 (i know, this is a mistake, but mistakes happen in production) :-)

 On the first request for the wrong object, varnish crashed.

 Analyzing the cache_vary.c, i found the code that causing this problem:

 line 123 of cache_vary.c

  xxxassert(*q == ',');

 i thought this patch attached would fix the problem, i did many tests, and
 had good results.

 I would like to know your opinion.

 ps: attached patch and strace.

 Regards,
 Daniel Biazus

-- 
Ticket URL: <http://varnish-cache.org/ticket/763>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Wed Aug 25 18:05:37 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Wed, 25 Aug 2010 18:05:37 -0000
Subject: [Varnish] #764: Varnish thinks the backend response is 0 bytes,
	but only when passing through for MSIE
Message-ID: <044.8fba0c9e911396c7e592226632e5c512@varnish-cache.org>

#764: Varnish thinks the backend response is 0 bytes, but only when passing
through for MSIE
----------------------+-----------------------------------------------------
 Reporter:  drwilco   |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  2.1.3
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
 When Firefox, wget or Chrome request any page (which we currently all just
 pass through), everything is fine. But when IE requests any page, only the
 headers are returned, and 0 bytes of content.

 Included are varnishlogs of similar requests done with IE, Firefox and
 wget, and pcaps of the traffic between varnish and the backend.

 As you can see the backend sends content back in all 3 cases, but Varnish
 doesn't see it in the IE case.

-- 
Ticket URL: <http://varnish-cache.org/ticket/764>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Fri Aug 27 14:36:33 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Fri, 27 Aug 2010 14:36:33 -0000
Subject: [Varnish] #765: [PATCH] varnishtop segfault i686
Message-ID: <040.8d0567caacbe6d708ea55db820b279eb@varnish-cache.org>

#765: [PATCH] varnishtop segfault i686
------------------------+---------------------------------------------------
 Reporter:  kwy         |       Owner:  phk                
     Type:  defect      |      Status:  new                
 Priority:  normal      |   Milestone:  Varnish 2.1 release
Component:  varnishtop  |     Version:  2.1.3              
 Severity:  normal      |    Keywords:                     
------------------------+---------------------------------------------------
 Segfault backtrace:

 Starting program: /root/varnish-2.1.3/bin/varnishtop/.libs/varnishtop
 [Thread debugging using libthread_db enabled]
 [New Thread 0xb75206b0 (LWP 22330)]
 [New Thread 0xb250eb90 (LWP 22333)]

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0xb250eb90 (LWP 22333)]
 0xb760fd55 in memcpy () from /lib/i686/cmov/libc.so.6
 #0  0xb760fd55 in memcpy () from /lib/i686/cmov/libc.so.6
 No symbol table info available.
 #1  0x08049181 in accumulate (p=0xb39d2f00 "\020") at varnishtop.c:122
         tp = (struct top *) 0x9cc3520
         tp2 = (struct top *) 0x1
         q = (const unsigned char *) 0xb39d2f0a ""
         u = 224
         l = 3
         i = 3
         __func__ = "accumulate"
 #2  0x0804953a in accumulate_thread (arg=0x9cad008) at varnishtop.c:197
         p = (unsigned char *) 0xb39d2f00 "\020"
         i = 1
         vd = (struct VSL_data *) 0x9cad008
 #3  0xb76f94c0 in start_thread () from /lib/i686/cmov/libpthread.so.0
 No symbol table info available.
 #4  0xb767884e in clone () from /lib/i686/cmov/libc.so.6
 No symbol table info available.
 #0  0xb760fd55 in memcpy () from /lib/i686/cmov/libc.so.6
 #1  0x08049181 in accumulate (p=0xb39d2f00 "\020") at varnishtop.c:122
 #2  0x0804953a in accumulate_thread (arg=0x9cad008) at varnishtop.c:197
 #3  0xb76f94c0 in start_thread () from /lib/i686/cmov/libpthread.so.0
 #4  0xb767884e in clone () from /lib/i686/cmov/libc.so.6
 quit


 patchfix diff:
 --- varnishtop.c.old    2010-08-27 16:32:29.000000000 +0200
 +++ varnishtop.c        2010-08-27 16:32:33.000000000 +0200
 @@ -55,7 +55,7 @@
  #include "varnishapi.h"

  struct top {
 -       unsigned char           rec[4];
 +       unsigned char           rec[6];
         unsigned char           *rec_data;
         unsigned                clen;
         unsigned                hash;

-- 
Ticket URL: <http://varnish-cache.org/ticket/765>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 30 11:22:09 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 30 Aug 2010 11:22:09 -0000
Subject: [Varnish] #764: Varnish thinks the backend response is 0 bytes,
	but only when passing through for MSIE
In-Reply-To: <044.8fba0c9e911396c7e592226632e5c512@varnish-cache.org>
References: <044.8fba0c9e911396c7e592226632e5c512@varnish-cache.org>
Message-ID: <053.6a5bfd87def62174c9b1a40c7ff00356@varnish-cache.org>

#764: Varnish thinks the backend response is 0 bytes, but only when passing
through for MSIE
----------------------+-----------------------------------------------------
 Reporter:  drwilco   |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  2.1.3
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------

Comment(by phk):

 This looks like a duplicate of #733, please try r5075 and see if that
 helps.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/764#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 30 11:28:24 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 30 Aug 2010 11:28:24 -0000
Subject: [Varnish] #762: varnishstat segfault
In-Reply-To: <044.faeba9b0cd4de3f6b34ab7116b045a3d@varnish-cache.org>
References: <044.faeba9b0cd4de3f6b34ab7116b045a3d@varnish-cache.org>
Message-ID: <053.c319cce0972ca8e69b958f094d7ee270@varnish-cache.org>

#762: varnishstat segfault
---------------------+------------------------------------------------------
 Reporter:  victori  |       Owner:  martin
     Type:  defect   |      Status:  new   
 Priority:  normal   |   Milestone:        
Component:  build    |     Version:  trunk 
 Severity:  normal   |    Keywords:        
---------------------+------------------------------------------------------
Changes (by phk):

  * owner:  => martin


-- 
Ticket URL: <http://www.varnish-cache.org/ticket/762#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 30 11:30:16 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 30 Aug 2010 11:30:16 -0000
Subject: [Varnish] #756: tests/c00031.vtc fails on RHEL6 beta2 / ppc64
In-Reply-To: <043.e34ebfca87896c1671e8c328f47fa932@varnish-cache.org>
References: <043.e34ebfca87896c1671e8c328f47fa932@varnish-cache.org>
Message-ID: <052.4aae6d4d8e96e6600ea979caf65a0fd3@varnish-cache.org>

#756: tests/c00031.vtc fails on RHEL6 beta2 / ppc64
--------------------+-------------------------------------------------------
 Reporter:  ingvar  |        Owner:        
     Type:  defect  |       Status:  closed
 Priority:  normal  |    Milestone:        
Component:  build   |      Version:  2.1.3 
 Severity:  normal  |   Resolution:  fixed 
 Keywords:          |  
--------------------+-------------------------------------------------------
Changes (by ingvar):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Changed to 256k in trunk. The patch for building latest stable release is
 trivial. Closing ticket.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/756#comment:5>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 30 11:30:50 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 30 Aug 2010 11:30:50 -0000
Subject: [Varnish] #757: tests/c00035.vtc fails on RHEL6 beta2 / ppc64
In-Reply-To: <043.1fe65b8fea39fb86bb41ce08de5f9861@varnish-cache.org>
References: <043.1fe65b8fea39fb86bb41ce08de5f9861@varnish-cache.org>
Message-ID: <052.faacc5b6df981065bc366a72bcf5e648@varnish-cache.org>

#757: tests/c00035.vtc fails on RHEL6 beta2 / ppc64
-------------------------+--------------------------------------------------
 Reporter:  ingvar       |        Owner:  phk   
     Type:  defect       |       Status:  closed
 Priority:  normal       |    Milestone:        
Component:  varnishtest  |      Version:  trunk 
 Severity:  normal       |   Resolution:  fixed 
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by ingvar):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Changed to 1s in trunk. Closing ticket.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/757#comment:3>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 30 11:32:35 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 30 Aug 2010 11:32:35 -0000
Subject: [Varnish] #761: critbit segfault
In-Reply-To: <040.60f07b58d2dfaf8df27b4a4d77300498@varnish-cache.org>
References: <040.60f07b58d2dfaf8df27b4a4d77300498@varnish-cache.org>
Message-ID: <049.c2b31494d48ee6b01614749dcaa4850e@varnish-cache.org>

#761: critbit segfault
----------------------+-----------------------------------------------------
 Reporter:  sky       |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  2.1.3
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------
Description changed by phk:

Old description:

> Panic message: Assert error in hcb_lookup(), hash_critbit.c line 475:
> Condition(!with_lock) not true. thread = (cache-worker) ident =
> Linux,2.6.32-24-server,x86_64,-sfile,-sfile,-sfile,-sfile,-sfile,-sfile,-hcritbit,epoll
> Backtrace: ??0x424878: /usr/sbin/varnishd() [0x424878] ??0x43182d:
> /usr/sbin/varnishd() [0x43182d] ??0x41e8e9:
> /usr/sbin/varnishd(HSH_Lookup+0x6a9) [0x41e8e9] ??0x412dab:
> /usr/sbin/varnishd() [0x412dab] ??0x4152fd:
> /usr/sbin/varnishd(CNT_Session+0x38d) [0x4152fd] ??0x426028:
> /usr/sbin/varnishd() [0x426028] ??0x4263fb: /usr/sbin/varnishd()
> [0x4263fb] ??0x7f31aeaff9ca: /lib/libpthread.so.0(+0x69ca)
> [0x7f31aeaff9ca] ??0x7f31ae3bf6fd: /lib/libc.so.6(clone+0x6d)
> [0x7f31ae3bf6fd] sp = 0x7e736c402008 { ??fd = 3453, id = 3453, xid =
> 1257538524, ??client = 74.79.40.95:58308, ??step = STP_LOOKUP, ??handling
> = hash, ??err_code = 503, err_reason = (null), ??restarts = 0, esis = 0
> ws = 0x7e736c402078 { ?????id = "sess", ????{s,f,r,e} =
> {0x7e736c402cd0,+3328,(nil),+131072}, ??}, ??http[req] = { ????ws =
> 0x7e736c402078[sess] ??????"GET",
> "/extensions/wikia/StaticChute/?type=css&packages=monaco_css_print&checksum=75a075dd32dd6479a937ee61cbd5940f",
> "HTTP/1.1", ??????"User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X
> 10_6_4; en-us) AppleWebKit/533.17.8 (KHTML, like Gecko) Version/5.0.1
> Safari/533.17.8", ??????"Accept: text/css,*/*;q=0.1", ??????"Referer:
> http://www.wowwiki.com/Portal:Main", ??????"Accept-Language: en-us",
> "Connection: keep-alive", ??????"X-Forwarded-From: varnish-i7-IOWA",
> "X-Forwarded-For: 74.79.40.95", ??????"Accept-Encoding: gzip",
> "host: www.wowwiki.com", ??????????"X-Logged-In: 0", ??}, ??worker =
> 0x7e7651478be0 { ????ws = 0x7e7651478d50 { ???????id = "wrk",
> {s,f,r,e} = {0x7e7651450b80,0x7e7651450b80,(nil),+131072}, ????}, ????},
> vcl = { ??????srcname = { ????????"input", ????????"Default",
> "/etc/varnish/yellowiki.vcl", ????????"/etc/varnish/SJC_backends.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/IOWA_backends.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/apache_healthcheck.vcl",
> "/etc/varnish/routing.vcl", ????????"/etc/varnish/wiki-stats.vcl",
> "/etc/varnish/misc.vcl", ????????"/etc/varnish/liftium_edge.vcl",
> "/etc/varnish/external_healthchecks.vcl",
> "/etc/varnish/riak_backends.vcl",
> "/etc/varnish/riak_healthcheck.vcl",
> "/etc/varnish/riak_healthcheck.vcl",
> "/etc/varnish/riak_healthcheck.vcl",
> "/etc/varnish/riak_healthcheck.vcl",
> "/etc/varnish/spotlights_edge.vcl", ????????"/etc/varnish/dev-
> backend.vcl", ????????"/etc/varnish/image

New description:

 {{{
 Panic message: Assert error in hcb_lookup(), hash_critbit.c line 475:
  ??Condition(!with_lock) not true. thread = (cache-worker)
  ident =
 Linux,2.6.32-24-server,x86_64,-sfile,-sfile,-sfile,-sfile,-sfile,-sfile,-hcritbit,epoll
 Backtrace:
  ??0x424878: /usr/sbin/varnishd() [0x424878]
  ??0x43182d: /usr/sbin/varnishd() [0x43182d]
  ??0x41e8e9: /usr/sbin/varnishd(HSH_Lookup+0x6a9) [0x41e8e9]
  ??0x412dab: /usr/sbin/varnishd() [0x412dab]
  ??0x4152fd: /usr/sbin/varnishd(CNT_Session+0x38d) [0x4152fd]
  ??0x426028: /usr/sbin/varnishd() [0x426028]
  ??0x4263fb: /usr/sbin/varnishd() [0x4263fb]
  ??0x7f31aeaff9ca: /lib/libpthread.so.0(+0x69ca) [0x7f31aeaff9ca]
  ??0x7f31ae3bf6fd: /lib/libc.so.6(clone+0x6d) [0x7f31ae3bf6fd]
  sp = 0x7e736c402008 {
  ??fd = 3453, id = 3453, xid = 1257538524,
  ??client = 74.79.40.95:58308,
  ??step = STP_LOOKUP,
  ??handling = hash,
  ??err_code = 503, err_reason = (null),
  ??restarts = 0, esis = 0
  ??ws = 0x7e736c402078 {
  ?????id = "sess",
  ????{s,f,r,e} = {0x7e736c402cd0,+3328,(nil),+131072},
  ??},
  ??http[req] = {
  ????ws = 0x7e736c402078[sess]
  ??????"GET",
 "/extensions/wikia/StaticChute/?type=css&packages=monaco_css_print&checksum=75a075dd32dd6479a937ee61cbd5940f",
  ??????"HTTP/1.1",
  ??????"User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-
 us) AppleWebKit/533.17.8 (KHTML, like Gecko) Version/5.0.1
 Safari/533.17.8",
  ??????"Accept: text/css,*/*;q=0.1",
  ??????"Referer: http://www.wowwiki.com/Portal:Main",
  ??????"Accept-Language: en-us",
  ??????"Connection: keep-alive",
  ??????"X-Forwarded-From: varnish-i7-IOWA",
  ??????"X-Forwarded-For: 74.79.40.95",
  ??????"Accept-Encoding: gzip",
  ??????"host: www.wowwiki.com",
  ??????????"X-Logged-In: 0",
  ??},
  ??worker = 0x7e7651478be0 { ????ws = 0x7e7651478d50 { ???????id = "wrk",
 {s,f,r,e} = {0x7e7651450b80,0x7e7651450b80,(nil),+131072}, ????}, ????},
 vcl = { ??????srcname = { ????????"input", ????????"Default",
 "/etc/varnish/yellowiki.vcl", ????????"/etc/varnish/SJC_backends.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/IOWA_backends.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl",
 "/etc/varnish/apache_healthcheck.vcl", ????????"/etc/varnish/routing.vcl",
 "/etc/varnish/wiki-stats.vcl", ????????"/etc/varnish/misc.vcl",
 "/etc/varnish/liftium_edge.vcl",
 "/etc/varnish/external_healthchecks.vcl",
 "/etc/varnish/riak_backends.vcl",
 "/etc/varnish/riak_healthcheck.vcl",
 "/etc/varnish/riak_healthcheck.vcl",
 "/etc/varnish/riak_healthcheck.vcl",
 "/etc/varnish/riak_healthcheck.vcl",
 "/etc/varnish/spotlights_edge.vcl", ????????"/etc/varnish/dev-
 backend.vcl", ????????"/etc/varnish/image
 }}}

--

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/761#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 30 11:34:32 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 30 Aug 2010 11:34:32 -0000
Subject: [Varnish] #760: varnishlog unbuffered output
In-Reply-To: <045.bbcca487396d337b069b2c55e4ee6665@varnish-cache.org>
References: <045.bbcca487396d337b069b2c55e4ee6665@varnish-cache.org>
Message-ID: <054.5e3a72fd58f557cdb0a854f561a880f2@varnish-cache.org>

#760: varnishlog unbuffered output
------------------------+---------------------------------------------------
 Reporter:  blade106    |       Owner:  martin           
     Type:  defect      |      Status:  new              
 Priority:  normal      |   Milestone:                   
Component:  varnishlog  |     Version:  2.1.3            
 Severity:  normal      |    Keywords:  varnishlog output
------------------------+---------------------------------------------------
Changes (by phk):

  * owner:  phk => martin


-- 
Ticket URL: <http://www.varnish-cache.org/ticket/760#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 30 12:01:09 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 30 Aug 2010 12:01:09 -0000
Subject: [Varnish] #765: [PATCH] varnishtop segfault i686
In-Reply-To: <040.8d0567caacbe6d708ea55db820b279eb@varnish-cache.org>
References: <040.8d0567caacbe6d708ea55db820b279eb@varnish-cache.org>
Message-ID: <049.f7b9a3b556332f9e1ae908019a2f98f8@varnish-cache.org>

#765: [PATCH] varnishtop segfault i686
------------------------+---------------------------------------------------
 Reporter:  kwy         |        Owner:  phk                
     Type:  defect      |       Status:  closed             
 Priority:  normal      |    Milestone:  Varnish 2.1 release
Component:  varnishtop  |      Version:  2.1.3              
 Severity:  normal      |   Resolution:  fixed              
 Keywords:              |  
------------------------+---------------------------------------------------
Changes (by tfheen):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 (In [5150]) Fix segfault on 32 bit machines

 Adjust the size of the rec field to match what's in shmlog.

 No corresponding -trunk commit as the code has been reworked already.

 Fixes #765

-- 
Ticket URL: </ticket/765#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Mon Aug 30 13:40:16 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Mon, 30 Aug 2010 13:40:16 -0000
Subject: [Varnish] #764: Varnish thinks the backend response is 0 bytes,
	but only when passing through for MSIE
In-Reply-To: <044.8fba0c9e911396c7e592226632e5c512@varnish-cache.org>
References: <044.8fba0c9e911396c7e592226632e5c512@varnish-cache.org>
Message-ID: <053.a6f9ed55115fc240a751a9bcde054af0@varnish-cache.org>

#764: Varnish thinks the backend response is 0 bytes, but only when passing
through for MSIE
----------------------+-----------------------------------------------------
 Reporter:  drwilco   |       Owner:  phk  
     Type:  defect    |      Status:  new  
 Priority:  normal    |   Milestone:       
Component:  varnishd  |     Version:  2.1.3
 Severity:  normal    |    Keywords:       
----------------------+-----------------------------------------------------

Comment(by drwilco):

 Applied changeset r5075 and that fixed it.

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/764#comment:2>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Aug 31 07:45:41 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 31 Aug 2010 07:45:41 -0000
Subject: [Varnish] #739: varnishlog sometimes reports backend logs as
	client logs
In-Reply-To: <043.60537f3fd7d53c8366decae348d0ce4c@varnish-cache.org>
References: <043.60537f3fd7d53c8366decae348d0ce4c@varnish-cache.org>
Message-ID: <052.95354a21abf8564c9d7c83f3ccd02f1a@varnish-cache.org>

#739: varnishlog sometimes reports backend logs as client logs
------------------------+---------------------------------------------------
 Reporter:  thoran      |        Owner:  martin
     Type:  defect      |       Status:  closed
 Priority:  normal      |    Milestone:        
Component:  varnishlog  |      Version:  2.1.2 
 Severity:  major       |   Resolution:  fixed 
 Keywords:              |  
------------------------+---------------------------------------------------
Changes (by martin):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 (In [5160]) Add explicit log flushing when backend connections close to
 keep log chronology. This is to avoid log lines for the same (reused) FD
 coming before the closing connection when load is high.

 Fixes #739

-- 
Ticket URL: </ticket/739#comment:4>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator



From varnish-bugs at varnish-cache.org  Tue Aug 31 10:06:41 2010
From: varnish-bugs at varnish-cache.org (Varnish)
Date: Tue, 31 Aug 2010 10:06:41 -0000
Subject: [Varnish] #766: Varnish Redirect Issue when User-Agent contains the
	string "connec"
Message-ID: <047.632b03fa3b724510b4e00eedefb615ee@varnish-cache.org>

#766: Varnish Redirect Issue when User-Agent contains the string "connec"
---------------------------------+------------------------------------------
 Reporter:  stefansinn           |        Type:  defect
   Status:  new                  |    Priority:  high  
Milestone:                       |   Component:  build 
  Version:  2.0                  |    Severity:  major 
 Keywords:  Redirect User-Agent  |  
---------------------------------+------------------------------------------
 when the User-Agent contains the string "connec" or "Connec" or "connect"
 or any combination with this string, then Varnish automatically issues a
 HTTP/1.1 301 Moved Permanently redirect.
 website: http://wetter.info

-- 
Ticket URL: <http://www.varnish-cache.org/ticket/766>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator