Pike-devel December 2020

pike-devel@lists.lysator.liu.se

2 participants
7 discussions

Pike Meet-up 2018-Q1
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 20 Oct '21

20 Oct '21

Hi. At Pike Conference 2017 it was decided that we ought to hold a more informal meeting in Linköping ~ once every quarter. As the three month mark from the conference is coming up soon, it seems time to announce the first such meeting for 2018: Pike Meet-up 2018-Q1 Date: 2018-02-03 (Sat) Time: 10:00 - afternoon/evening Place: Roxen IS AB S:t Larsgatan 22A Linköping Welcome! /grubba

2 13

8.0 test suite failures: fork() + time on macOS 10.12+
by H William Welliver 06 Jan '21

06 Jan '21

I’m running builds of 8.0 to make sure we don’t have any major test failures, and I’ve run into a few problems so far. I’ll put them in separate emails so they are more manageable. If anyone can offer any assistance, that would be most appreciated. I can supply any info needed, up to getting you a logon to the systems in question. First up, macOS 10.12+ hang on socktest.pike. The 10.11 and earlier do not have this problem, and I haven’t tried running an older binary on a newer OS. The call to gc() in finish() never returns, and according to LLDB: (lldb) thread list Process 4746 stopped * thread #1: tid = 0xa7cc2d, 0x00007fff781f922a libsystem_kernel.dylib`mach_msg_trap + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP (lldb) thread backtrace * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x00007fff781f922a libsystem_kernel.dylib`mach_msg_trap + 10 frame #1: 0x00007fff781f976c libsystem_kernel.dylib`mach_msg + 60 frame #2: 0x00007fff781fd05e libsystem_kernel.dylib`clock_get_time + 85 frame #3: 0x0000000105974667 pike`mach_clock_get_time at rusage.c:633:7 frame #4: 0x00000001058e713b pike`do_gc(ignored_UNUSED=<unavailable>, explicit_call=<unavailable>) at gc.c:3507:24 frame #5: 0x00000001059ee723 pike`f_gc(args=<unavailable>) at builtin_functions.c:5126:11 frame #6: 0x00000001063607b7 frame #7: 0x00000001058a365a pike`mega_apply [inlined] eval_instruction(pc=<unavailable>) at interpret.c:1711:5 frame #8: 0x00000001058a3658 pike`mega_apply(type=<unavailable>, args=<unavailable>, arg1=<unavailable>, arg2=<unavailable>) at interpret.c:2695 frame #9: 0x000000010589c72d pike`apply_svalue(s=<unavailable>, args=<unavailable>) at interpret.c:3158:5 frame #10: 0x0000000105a31769 pike`got_fd_event(box=0x0000000105de5008, event=937461904) at file.c:368:5 frame #11: 0x00000001058c901f pike`backend_call_active_callbacks(fd_list=0x00007ffeea373ae8, me_UNUSED=<unavailable>) at backend.cmod:2349:6 frame #12: 0x00000001058c4839 pike`pdb_low_backend_once(pdb=0x00007fef37e086d0, timeout=0x00007ffeea373fa8) at backend.cmod:4137:11 frame #13: 0x00000001058c4aec pike`f_PollDeviceBackend_cq__backtick_28_29(args=1) at backend.cmod:4315:5 frame #14: 0x00000001058a1cbc pike`low_mega_apply(type=APPLY_SVALUE, args=1, arg1=<unavailable>, arg2=<unavailable>) at apply_low.h:221:2 frame #15: 0x00000001058a2753 pike`jump_opcode_F_CALL_FUNCTION_AND_POP at interpret_functions.h:2452:1 frame #16: 0x00000001061d4348 Some other information I discovered looking into this: I tried to add some sleep() in the child process in order to examine the process with dtrace, but the sleep() never returned. Sleep seems to work fine with a pike -e ’sleep(5);’. If I disable the fork(), the test runs successfully. The following test case demonstrates the problem. The sleep() can be exchanged for gc() and it also hangs. int main() { object pid; if (mixed err = catch { pid = fork(); }) { werror("fork() failed\n"); } else if (pid) { int res = pid->wait(); werror("child exited.\n"); return 0; } werror("child\n"); sleep(2); werror("slept\n"); return 0; } bin/pike test2.pike child I don’t quite understand why clock_get_time() would hang like that unless there was some sort of problem with the mach clock service across processes, though it wouldn’t surprise me if that were a problem. What is also interesting is that clock_gettime() is available in 10.12 and newer. According to the manpage, this is POSIX compliant and provides CLOCK_MONOTONIC, which is what is used on some other systems. There is a problem in that _POSIX_MONOTONIC_CLOCK is set to -1, which seems to contradict the man page. Not sure if it makes sense to try that instead, or re-initialize the clock service after the fork? Bill

2 2

Pike 8.0.1116 (release)
by H William Welliver 31 Dec '20

31 Dec '20

I’ve cut a new version of Pike 8.0 that includes the missing change log entry as well as a minor fix that hopefully fixes a compile error in the latest version of macOS. The builds all look good so I’m going to declare this an official stable release. Please feel free to upload binaries; I’m going to start working on a set of macOS releases. Unless something goes horribly wrong in the next 24 hours, I’ll announce the new version in a few days. http://pike.lysator.liu.se/download/pub/pike/all/8.0.1116/ Also, what’s the status of Win32 builds? I think my build environment is a bit out of date relative to the last few releases. Bill

3 6

8.0.1116 tarball
by william＠welliver.org 27 Dec '20

27 Dec '20

All- I've discovered that the source tarball contains a handful of extraneous files: a pair of droppings from patch as well as a pair of temporary files my text editor seems to have made (but which I can't find outside the archive). There's nothing of any note in the files, but I don't think they should be allowed to remain. Does anyone have a preference for how I handle this? The "by the book" method would be for me to run make export again, with all that entails, but I could also be persuaded to just remove the files from the archive and re-upload it if that would be less work for others. Also, might it be a good idea to have the export process check for this sort of thing, or maybe operate from a fresh export of the repository? Not sure what the right approach would be... opinions are welcome. Bill

2 1

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

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