[jira] [Assigned] (TS-857) Crash Report: HttpTunnel::chain_abort_all -> HttpServerSession::do_io_close -> UnixNetVConnection::do_io_close

2012-04-12 Thread Brian Geffon (Assigned) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Geffon reassigned TS-857:
---

Assignee: Brian Geffon  (was: weijin)

> Crash Report: HttpTunnel::chain_abort_all -> HttpServerSession::do_io_close 
> -> UnixNetVConnection::do_io_close
> --
>
> Key: TS-857
> URL: https://issues.apache.org/jira/browse/TS-857
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, Network
>Affects Versions: 3.1.0
> Environment: in my branch that is something same as 3.0.x
>Reporter: Zhao Yongming
>Assignee: Brian Geffon
> Fix For: 3.1.4
>
> Attachments: TS-857-jp1.patch, locking-jp1.patch, ts-857.diff, 
> ts-857.diff, ts-857.diff
>
>
> here is the bt from the crash, some of the information is missing due to we 
> have not enable the --enable-debug configure options.
> {code}
> [New process 7532]
> #0  ink_stack_trace_get (stack=, len= out>, signalhandler_frame=)
> at ink_stack_trace.cc:68
> 68fp = (void **) (*fp);
> (gdb) bt
> #0  ink_stack_trace_get (stack=, len= out>, signalhandler_frame=)
> at ink_stack_trace.cc:68
> #1  0x2ba641dccef1 in ink_stack_trace_dump (sighandler_frame= optimized out>) at ink_stack_trace.cc:114
> #2  0x004df020 in signal_handler (sig=) at 
> signals.cc:225
> #3  
> #4  0x006a1ea9 in UnixNetVConnection::do_io_close (this=0x1cc9bd20, 
> alerrno=)
> at ../../iocore/eventsystem/I_Lock.h:297
> #5  0x0051f1d0 in HttpServerSession::do_io_close 
> (this=0x2aaab0042c80, alerrno=20600) at HttpServerSession.cc:127
> #6  0x0056d1e9 in HttpTunnel::chain_abort_all (this=0x2aabeeffdd70, 
> p=0x2aabeeffdf68) at HttpTunnel.cc:1300
> #7  0x005269ca in HttpSM::tunnel_handler_ua (this=0x2aabeeffc070, 
> event=104, c=0x2aabeeffdda8) at HttpSM.cc:2987
> #8  0x00571dfc in HttpTunnel::consumer_handler (this=0x2aabeeffdd70, 
> event=104, c=0x2aabeeffdda8) at HttpTunnel.cc:1232
> #9  0x00572032 in HttpTunnel::main_handler (this=0x2aabeeffdd70, 
> event=1088608784, data=)
> at HttpTunnel.cc:1456
> #10 0x006a6307 in write_to_net_io (nh=0x2b12d688, vc=0x1cc876e0, 
> thread=)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #11 0x0069ce97 in NetHandler::mainNetEvent (this=0x2b12d688, 
> event=, e=0x171c1ed0) at UnixNet.cc:405
> #12 0x006cddaf in EThread::process_event (this=0x2b12c010, 
> e=0x171c1ed0, calling_code=5) at I_Continuation.h:146
> #13 0x006ce6bc in EThread::execute (this=0x2b12c010) at 
> UnixEThread.cc:262
> #14 0x006cd0ee in spawn_thread_internal (a=0x171b58f0) at Thread.cc:88
> #15 0x003c33c064a7 in start_thread () from /lib64/libpthread.so.0
> #16 0x003c330d3c2d in clone () from /lib64/libc.so.6
> (gdb) info f
> Stack level 0, frame at 0x40e2b790:
>  rip = 0x2ba641dccdf3 in ink_stack_trace_get(void**, int, int) 
> (ink_stack_trace.cc:68); saved rip 0x2ba641dccef1
>  called by frame at 0x40e2bbe0
>  source language c++.
>  Arglist at 0x40e2b770, args: stack=, len= optimized out>, signalhandler_frame=
>  Locals at 0x40e2b770, Previous frame's sp is 0x40e2b790
>  Saved registers:
>   rbx at 0x40e2b778, rbp at 0x40e2b780, rip at 0x40e2b788
> (gdb) 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-1192) Remove gethostbyname usage in test code

2012-04-08 Thread Brian Geffon (Assigned) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-1192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Geffon reassigned TS-1192:


Assignee: Brian Geffon

> Remove gethostbyname usage in test code
> ---
>
> Key: TS-1192
> URL: https://issues.apache.org/jira/browse/TS-1192
> Project: Traffic Server
>  Issue Type: Improvement
>Affects Versions: 3.1.3
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 3.1.4
>
>
> NetTest-simple-proxy.cc and test_I_simple_proxy.cc directly use 
> gethostbyname(). These will be changed to use getaddrinfo().
> We're removing gethostbyname() and gethostbyaddr() in an effort to get 
> traffic server building on more platforms.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-1065) traffic_cop segment fault when enable TRACE_LOG_COP

2012-02-25 Thread Brian Geffon (Assigned) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Geffon reassigned TS-1065:


Assignee: Brian Geffon  (was: Igor Galić)

> traffic_cop segment fault when enable TRACE_LOG_COP
> ---
>
> Key: TS-1065
> URL: https://issues.apache.org/jira/browse/TS-1065
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 3.1.1, 3.0.2
> Environment: mac os 10.7.2, centos 5.4 64bit
>Reporter: Conan Wang
>Assignee: Brian Geffon
>Priority: Minor
> Fix For: 3.1.2
>
> Attachments: traffic_cop.diff
>
>
> When enable traffic_cop's debug log:  #define TRACE_LOG_COP 1 
> Some cop_log invocation will cause segment fault, because va_list object in 
> cop_log is used twice between 'va_start' and 'va_end'.
> {code}
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x
> 0x7fff846b64f0 in strlen ()
> (gdb) bt
> #0  0x7fff846b64f0 in strlen ()
> #1  0x7fff846578c3 in __vfprintf ()
> #2  0x7fff846a109b in vsprintf_l ()
> #3  0x00011883 in cop_log (priority=5, format=0x172a8 "--- Cop 
> Starting [Version: %s] ---\n") at TrafficCop.cc:172
> #4  0x00012244 in check_lockfile () at TrafficCop.cc:1733
> #5  0x000122c0 in init () at TrafficCop.cc:1894
> #6  0x00016689 in main (argc=1, argv=0x7fff5fbffbb0) at 
> TrafficCop.cc:1958
> {code}
> Reference:
> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdarg.h.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-935) Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT

2012-02-17 Thread Brian Geffon (Assigned) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Geffon reassigned TS-935:
---

Assignee: Brian Geffon

> Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT
> 
>
> Key: TS-935
> URL: https://issues.apache.org/jira/browse/TS-935
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Affects Versions: 3.0.1
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 3.1.3
>
>
> When trying to use TSContCall with event = TS_EVENT_TIMEOUT I stumbled upon 
> the fact that the API will decrement the event count for EVENT_INTERNAL or 
> EVENT_IMMEDIATE (see INKContInternal::handle_event_count), but shouldn't we 
> be able to do a TSContCall with TS_EVENT_IMMEDIAITE or TS_EVENT_TIMEOUT 
> because as of now doing so would cause m_event_count to become -1 or 
> shouldn't these defined values be something different? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-1110) logstats incorrectly bucketizes all status codes greater than 599 as 5xx

2012-02-15 Thread Brian Geffon (Assigned) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Geffon reassigned TS-1110:


Assignee: Brian Geffon

> logstats incorrectly bucketizes all status codes greater than 599 as 5xx
> 
>
> Key: TS-1110
> URL: https://issues.apache.org/jira/browse/TS-1110
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Stats
>Affects Versions: 3.0.3
>Reporter: Manjesh Nilange
>Assignee: Brian Geffon
> Attachments: logstats.cc.patch
>
>
> logstats incorrectly bucketizes all status codes greater than 599 as 5xx. If 
> people use custom status codes (999 for example), this will get counted as a 
> 5xx status.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-1035) EventProcessor::spawn_thread doesn't check that there is enough event threads and segfaults

2012-01-24 Thread Brian Geffon (Assigned) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Geffon reassigned TS-1035:


Assignee: Brian Geffon  (was: Leif Hedstrom)

> EventProcessor::spawn_thread doesn't check that there is enough event threads 
> and segfaults
> ---
>
> Key: TS-1035
> URL: https://issues.apache.org/jira/browse/TS-1035
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.0.1
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 3.1.3
>
> Attachments: LargeNumberOfPorts.patch, UnixEventProcessor.patch
>
>
> The easiest way to see this bug is to use several hundred ports with accept 
> threads turned on. The bug exists because in I_EventProcessor.h there is a 
> hard coded limit of 512 event threads and there is no check in spawn_thread 
> that you haven't exceeded that limit so it will result in a segfault if 
> you're creating too many threads. From what I can tell the best solution is 
> an assertion that you haven't exceeded MAX_EVENT_THREADS.
> Patch is included.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira