Pike-devel December 2020

pike-devel@lists.lysator.liu.se

2 participants
13 discussions

Pike 8.0 RC
by H William Welliver 16 Dec '20

16 Dec '20

Hello Pike friends, I’ve prepared a release candidate of Pike 8.0 that I hope will sail through some user testing. I’ve fixed a number of problems and most of the test failures I’ve seen on non linux systems (macOS, Solaris/illumos, NetBSD, FreeBSD) are either fixed or easily explained. There is a change log entry that didn’t make the tarball, but I’m not going to bump the version just for that. Please have a look and let me know if you find any problems. If all goes well, I’ll declare this a stable release in 7 days, after which we can build binaries. http://pike.lysator.liu.se/pub/pike/beta/8.0.1110Pike-v8.0.1110.tar.gz Thanks and as always, comments and suggestions are welcome! Bill

1 0

Re: Pike stable build
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 03 Dec '20

03 Dec '20

>SSL.File->read() will throw an exception if the connection is closed >at the time of the call, regardless of whether there¢s data to be >read. That¢s certainly a divergence from Stdio.Fd->read(). It's also completely useless. That way you will never be able to get data the server sends just before it closes the connection. I'd say the testsuite did a good job of finding a serious bug here.

2 1

Pike stable build
by william＠welliver.org 03 Dec '20

03 Dec '20

Update: I've got most of the critical problems sorted out in preparation of a new 8.0 build. I've noticed that there are a number of SSL test suite failures, particularly on my NetBSD systems, but a number of pikefarm clients also report failures. I spent the afternoon digging around and it looks like they're all timing related. Does anyone have an objection to me increasing the amount of time individual tests in question are allowed to run? Based on my read of the code, there is only 1 spot where doing so would make the tests run longer on (faster) systems unaffected by the problem. That's basically a spot where a SSL server thread writes some data and immediately closes the connection. The client thread first checks to see if the SSL.File is closed before reading and fails occasionally. Adding a bit of sleep() between the write() and close() on the server thread gives the client some time to get past that check before the server closes the connection. I recognize that is not the best way to solve the problem, but I'd like to get a release candidate prepared in the next few days. I will do so and get an RC prepared tomorrow afternoon if I don't hear any objections. Thanks in advance! Bill

3 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pike-devel December 2020