Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1503
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1503
Something that should be considered moving forward is how (or whether)
server session sharing needs to be augmented to take the client cert
requirements into account.
---
If your project
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1532
Built with jemalloc and installed on same machine. Does not crash anymore,
but the load average is crazy (25-30). spinlock shows up as 25% CPU in perf
top and IOBuffer::read_avail shows
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1532
I installed on a machine with a higher load, and it fails in ats_memalign
from freelist_new within 2 minutes of traffic. Watching top the amount of
memory used by the process is much
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1565
Fix Assertion failure in the regex_revalidate plugin.
Since TS-4387, Calls to TSContSchedule/TSContScheduleEvery(), require
that the continuation associated with the TSCont parameter
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1561
@jrushford fixed this for 6.2.x. I'm putting up a PR with a cherry-pick of
his fix.
---
If your project is set up for it, you can reply to this email and have your
reply appear
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1561
A new 7.1 Crash
After running in production for 2.5 days without incident (with a couple
fixes now merged back to 7.1.x), I got a core with the following stack trace
```
(gdb) bt
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1544
Also reported via issue #1498. I think there is a problem with freeing
memory if the free list is deallocated (-f). When I accidentally left the -f
flag on after I reinstalled a non
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1547
Fix ssl hook state logic.
Was not correctly resetting the ssl hook state after the servername hooks.
You can merge this pull request into a Git repository by running:
$ git pull https
Github user shinrich commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/1446#discussion_r104750433
--- Diff: iocore/net/SSLNetVConnection.cc ---
@@ -1438,17 +1438,22 @@ bool
SSLNetVConnection::callHooks(TSEvent eventId)
{
// Only
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1522
I ran my production box overnight with the latest work around. I think
this change is a step in the right direction and we should merge it and bring
it back to 7.1.
---
If your project
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1522
I think the issue raised by @scw00 is different. It looks like what @zwoop
identified in issue #1531. In that case the write vio errored, so the write
vio is being sent up as data
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1456
http2 connections are tracked by
proxy.process.http2.current_client_sessions and
proxy.process.http2.total_client_connections.
All successfully negotiated SSL/TCP connections would
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1532
I saw stacks like this when I was running with the free list disabled (-f).
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1476
I had two more asserts once I added back in the accept thread. Upon deeper
inspection, the last alloc time and the UA_BEGIN time were off by half a ms, so
I am attributing that to clock
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1476
Have been adding member variables to NetVConnection and adding assert to
HttpSM::state_api_callout.
In the cores it seemed that the crash always happened in the first hook
called
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1532
Any indication of object buildup in a particular type of object pool?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1531
Oh, nevermind. I saw vio = NULL in the stack, but that is the local
variable.
That makes sense that the event would be passing up the write via. It is a
write event we
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1531
The server_entry->read_vio is NULL. From what I can tell this value only
gets set due to do_io_read() calls in attach_server_session() and
setup_server_read_response_hea
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1476
Still struggling with this issue. Running into it every 2-4 hours in
production. At this point, I think it is a use-after-free, but as noted avoid
ASAN fails in this case
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1498
Actually it looks like the issue is just tracking down the particular issue
in #1476 / #1480.
I enabled ASAN while merging in another issue, and it caught the double
free
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1527
So do you think this is making a real performance difference? Or are we
just not timing out connections as quickly now?
I hadn't noticed a difference in number of active
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1526
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1526
Yes, I suppose since it is a latent issue and not a regression it doesn't
need to be in the 7.1 train. We will separately pull it into our version. Set
version to 7.2
---
If your
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1444
Closing in deference to the more complete solution in PR #1522
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1444
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1526
When SSL connect fails, we return 502 success
While debugging a failure in origin cert verification, we saw that the
response header included
```
HTTP/1.1 502 Success
Date
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1522
Looks reasonable to me.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1525
Should allow control on whether default cert paths/files are included for
verification
When creating the SSL_CTX for ATS initiating connections to origin, we
always call
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1446
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1445
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1459
Yes, this is still an issue. I need to do some more testing on PR #1446.
Some variant of that will need to be added to 7.1.
---
If your project is set up for it, you can reply
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1511
Looks reasonable to me.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1480
I think this is the same underlying issue as issue #1476. Another case of
calling a virtual method into a VC.
---
If your project is set up for it, you can reply to this email and have
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1476
Very odd bug. Most of the crashes are in get_client_addr or
get_remote_addr. In both cases, the problem is at the point of the virtual
method call into the corresponding test. The RAX
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1498
The gcc in devtoolset-3 (gcc 4.9.2) and devtoolset-4 (gcc 5.3.1).
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1498
Problems with ASAN builds in 7.1
When running ASAN builds with the 7.1.x codebase I no longer see nice
use-after-free reports (for the most part). Instead I see repeats of the
following pair
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1401
Finally get a use-after-free ASAN stack in this area. Anyone else having
problems with ASAN in newer builds?
Looks like it is showing a use after free in the case of the error
Github user shinrich commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/1488#discussion_r103023456
--- Diff: iocore/net/SSLUtils.cc ---
@@ -2007,7 +2007,10 @@ SSLParseCertificateConfiguration(const
SSLConfigParams *params, SSLCertLookup *l
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1480
Crash in Http1ClientSession::set_inactivity_timeout
While testing 7.1, we see the following crash and stack track
```
#0 0x in ?? ()
#1 0x005d6794
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1446
Updated PR to address issue #1459
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1476
Crash in get_client_addr()
After working through issues #1401 and #1443, we now see the following
crash in our copy of 7.1. The crash occurs once every couple hours.
```
#0
Github user shinrich closed the issue at:
https://github.com/apache/trafficserver/issues/1369
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1369
Change committed.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1421
Related discussion on issue #1401. I have a hacky PR related to that
issue, which has enabled us to continue on. It is definitely triggered by the
error bubbling changes. I didn't pin
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1459
Found this was an issue in the changes made in our version of 7.1 shown in
PR #1446. I will update the PR with the fix. As it stands, if there is no
servername hook, the cert hook
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1459
Mysterious uptick in user_agent SSL errors moving to 7.1
Comparing a machine running 7.1.x against its peer running our version of
5.3.x. A number of the proxy.process.ssl.user_agent_
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1444
Yes, as I said not an entirely satisfying solution. I do thing the issue
is triggered by the changes from TS-4796 where @jacksontj added logic to bubble
up these errors. I'm guessing
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1452
ssl_callback_ocsp_stapling spew of messages in diags.log on start
On system start with 7.1, I see lots of the following messages in diags.log
for a few minutes. It eventually stops
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1445
An assert triggers. A stack trace in the issue description.
https://github.com/apache/trafficserver/issues/1443
---
If your project is set up for it, you can reply to this email
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1446
Need dedicated TS_SSL_SERVERNAME_HOOK
If you have a plugin that needs to trigger on every TLS client hello, this
won't
work the TS_SSL_SNI_HOOK with openssl-1.0.2. In that version
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1445
Issue #1443 - Fix early or duplicate 404 error handling
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shinrich/trafficserver
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1444
issue #1401: Potential fix to the write_to_io_net crash.
Not a super satisfying solution. Without this change, ats 7.1 would crash
immediately in our production environment
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1443
Tracked it down some more. In this case, new remap rule is not found, and
build_error_response is called to set the status of 404 with the reason of "Not
Found". B
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1443
Assert on null t_state.transact_return_point
Seeing this crash now after putting in work around for issue #1401.
```
#0 0x2b20159b7625 in raise () from /lib64/libc.so.6
#1
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1401
BTW I'm currently testing without HTTP/2.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1401
@PSUdaemon would be cool to see symbols with the stack to verify that is
the same thing. My hacky fix made it go away only to be immediately replaced
by a new crash. (New issue
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1401
I've finally got my environment running and I see the same stack very
quickly as well. In the cases I've seen it looks like there was a write error,
but for some reason the write vio has
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1248
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1365
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1387
Add diags log message when cache wraps.
Requested by our operations guys to better track wraps.
You can merge this pull request into a Git repository by running:
$ git pull https
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1375
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1365
Replaced NULL references with nullptr
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1379
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1370
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1375
The client session gets cleaned up as normal after the response is sent.
The problem is the original code was cleaning up the client session via the
kill tunnel before sending the error
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1376
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1379
Make sure to schedule connect event on correct thread type.
Cannot blindly schedule on current thread. It may not be the right type.
You can merge this pull request into a Git repository
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1376
TSStringPercentDecode null-termination clipping on overflow.
Actually fixed by @petar last summer, but forgot to get it pushed to up.
Long URL's would cause buffer overflow write
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1370
Addressed Alan's comment.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1375
Incorrectly freeing Http1ClientSession setting up to return a error
Saw a very deep stack. The following is the stop of the stack.
{code}
#0 0x in ?? ()
#1
Github user shinrich commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/1370#discussion_r97871781
--- Diff: proxy/http/HttpSM.cc ---
@@ -4933,8 +4933,10 @@ HttpSM::do_http_server_open(bool raw)
// between the statement above and the check
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1370
Ok. Still figuring out the new world order :-)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1366
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1366
Probably. We will be pulling this back into our 7.1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1367
Hopefully this fixes what you saw @maskit. Looking at the discussion on
TS-2792 had it been solved before?
---
If your project is set up for it, you can reply to this email and have
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1368
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1370
Issue #1369: proxy.config.http.server_max_connections over limit fail
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shinrich
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1369
proxy.config.http.server_max_connections over limit should fail immediately
The way it is currently encoded, requests over the connection limit delay
100ms and try again. This doesn't help ATS
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1368
Issue #1367: HdrHeap potential corruption
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shinrich/trafficserver issue-1367
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1367
HdrHeap potential corruption
Would see this sometimes during the host header manipulation. The original
code assumes that the string pointer from the field will stay static over other
header
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1366
Issue #1360: REGRESSION_TEST(SDK_API_OVERRIDABLE_CONFIGS) crash sometimes
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shinrich
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1364
Would be reasonable to backport. We will be pulling it back into our
version of 7.1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1365
TS-4896: TSHttp***ClientAddrGet/TSHttp***IncomingAddrGet may return NULL
Several of our plugins would experience crashes once we tightened up clean
up on session shutdown. They assumed
Github user shinrich closed the issue at:
https://github.com/apache/trafficserver/issues/1358
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1358
Fix commited
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1364
Issue #1359: Flaw in TS-2157 port in server address may be unset
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shinrich
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1361
Issue #1358: Add server_connect_end in slow log
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shinrich/trafficserver issue-1358
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1360
REGRESSION_TEST(SDK_API_OVERRIDABLE_CONFIGS) sometimes crashes
Due to timing changes in cleaning up sessions and state machines sometimes
REGRESSION_TEST(SDK_API_OVERRIDABLE_CONFIGS) crashes
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1359
Flaw in TS-2157 means that port in server address is unset
This is only an issue if the request to origin is a non-standard port.
---
If your project is set up for it, you can
GitHub user shinrich opened an issue:
https://github.com/apache/trafficserver/issues/1358
Should add server_connect_end to the milestones
We added this milestone entry a while back to help debug a performance
problem. Would like to contribute this back.
---
If your
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1347
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1347
Looks good to me. Explicitly checking that both the path and file name are
NULL should avoid bogus load attempts. Still odd that relative layout logic
uses getcwd if the path is NULL
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1315
Looks good.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1315
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1308
Both issues have been addressed.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user shinrich closed the issue at:
https://github.com/apache/trafficserver/issues/1308
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/1314
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/issues/1308
PR #1314 should fix CID 1368315
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1314
Fix Http2Stream *stream variable shadow reported by issue 1308.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shinrich/trafficserver
1 - 100 of 343 matches
Mail list logo
