On Tue, Sep 21, 2010 at 9:33 AM, John Plevyak <[email protected]> wrote: > > > OK, I pulled 2.1.2, and it crashes almost immediately for on the same > test that the SVN version runs overnight on. > > I would say that 2.1.2 has a bug which has been fixed. > > Please try SVN and we'll see about expediting the next version. >
The configure is giving me some problem. svn checkout http://svn.apache.org/repos/asf/trafficserver/traffic/trunk trafficserver cd trafficserver/ autoreconf -i --force Putting files in AC_CONFIG_AUX_DIR, `build/aux'. configure.ac:145: error: possibly undefined macro: AC_MSG_RESULT If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:214: error: possibly undefined macro: AS_IF configure.ac:828: error: possibly undefined macro: AC_MSG_FAILURE configure.ac:1041: error: possibly undefined macro: AS_CASE autoreconf: /usr/bin/autoconf failed with exit status: 1 The configure script was created so I went ahead and ran it, with this failure checking for sys/capability.h... yes ./configure: line 28167: syntax error near unexpected token `"$enable_tproxy",' ./configure: line 28167: ` AS_CASE("$enable_tproxy",' The only difference in configure.ac between trunk and 2.1.2 is related to tproxy. So I removed that and it goes further, but the make fails in UnixConnection.cc, which is probably caused by my changes, since it fails at ATS_USE_TPROXY. Let me know if I missed something. Thanks -- Pranav > john > > > On 9/20/2010 9:45 PM, Pranav Desai wrote: >> On Mon, Sep 20, 2010 at 9:34 PM, John Plevyak <[email protected]> wrote: >>> >>> All of these are cache corruption issues. I can't seem to reproduce them >>> locally. >>> >>> Are you running the latest SVN ? There was a bug in the SVN version of ATS >>> a little while ago for a couple days before it got fixed. >>> >> >> This is with 2.1.2. Maybe I will try the latest SVN. >> >>> Did you clear the cache before running (start with traffic_server -K)? >>> Changes >>> in the cache format are supposed to be tracked by versioning of the >>> database, but >>> there might have been a change which wasn't accompanied by a version bump. >>> >> >> I have tried it with -K -k, but same result. In fact I clean out all >> the files logs and cache.db before every run. Could it possible be >> hard drive issues ... I am thinking of trying another machine. Also >> note that I am testing it with a file based cache. Do you think there >> could be something there ? >> >> >>> If can provide access to a gdb session with the crash I might be able to >>> figure >>> out what is going on... >>> >> >> I was short on time so couldn't debug it any further ... hopefully I >> can get it done tomorrow ... >> >> -- Pranav >> >>> john >>> >>> >>> On 9/20/2010 6:20 PM, Pranav Desai wrote: >>>> On Thu, Sep 16, 2010 at 3:30 PM, Pranav Desai <[email protected]> >>>> wrote: >>>>> On Thu, Sep 16, 2010 at 2:03 PM, Leif Hedstrom <[email protected]> wrote: >>>>>> On 09/16/2010 02:45 PM, Pranav Desai wrote: >>>>>> >>>>>> On Thu, Sep 16, 2010 at 12:33 PM, Leif Hedstrom <[email protected]> wrote: >>>>>> >>>>>> On 09/16/2010 01:26 PM, Pranav Desai wrote: >>>>>> >>>>>> Hi! >>>>>> >>>>>> I am running a load test with some video files to see . I am using >>>>>> curl-loader to generate the load. I have modified it to add a random >>>>>> number to the URLs before sending so I can test with a single URL and >>>>>> still stress the cache. The webserver is a lighttpd server with >>>>>> rewrite rules to translate the random strings back to a common URL. >>>>>> The URL is essentially a 15MB video file. I can provide more details >>>>>> on the setup if needed. >>>>>> >>>>>> Ok, I've created https://issues.apache.org/jira/browse/TS-441 with this >>>>>> information. If you can find a core file (or, run traffic_server under >>>>>> gdb), >>>>>> and get a stack trace, that would be very helpful. Also, when it crashes, >>>>>> you might get a stack trace in /var/log/messages and/or one of the log >>>>>> files >>>>>> in the .../var/log/trafficserver directory. >>>>>> >>>>>> >>>> >>>> I got the stack trace. I have updated the bug with the trace, but here it >>>> is. >>>> >>>> FATAL: HTTP.cc:1526: failed assert `!"unknown m_polarity"` >>>> ./bin/traffic_server - STACK TRACE: >>>> ./bin/traffic_server(ink_fatal+0x86)[0x6f2056] >>>> ./bin/traffic_server(_ink_assert+0x81)[0x6f0d61] >>>> ./bin/traffic_server(_ZN11HTTPHdrImpl9unmarshalEl+0x35)[0x5ea385] >>>> ./bin/traffic_server(_ZN7HdrHeap9unmarshalEiiPP14HdrHeapObjImplP11RefCountObj+0x146)[0x5df926] >>>> ./bin/traffic_server(_ZN8HTTPInfo9unmarshalEPciP11RefCountObj+0xc5)[0x5ea205] >>>> ./bin/traffic_server(_ZN7CacheVC14handleReadDoneEiP5Event+0x750)[0x6648a0] >>>> ./bin/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x26)[0x66ce26] >>>> ./bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x22f)[0x6e7c0f] >>>> ./bin/traffic_server(_ZN7EThread7executeEv+0x1aa)[0x6e810a] >>>> ./bin/traffic_server[0x6e76da] >>>> /lib64/libpthread.so.0[0x7f4a565e52e7] >>>> /lib64/libc.so.6(clone+0x6d)[0x32a18ce3bd] >>>> >>>> >>>> I will try to dig deeper, but if have any ideas or suggestions I can >>>> try those out. >>>> >>>> Thanks >>>> -- Pranav >>> >>> > >
