Pike-devel March 2016

pike-devel@lists.lysator.liu.se

7 participants
16 discussions

Start a nNew thread

random on iterators
by Martin Nilsson (Coppermist) ＠ Pike (-) developers forum 14 Mar '16

14 Mar '16

How stable are Mapping.Iterator and Multiset.Iterator? Is the order guaranteed, platform dependent or something else?

2 4

Pike 8.0.182 release candidate
by Peter Bortas 10 Mar '16

10 Mar '16

Release candidate for testing: https://pike.lysator.liu.se/pub/pike/beta/8.0.182/Pike-v8.0.182.tar.gz Changes since Pike 8.0.164 (current stable) ---------------------------------------------------------------------- New features ------------ o gc It is now possible to run the gc in a quick mode to just cut weak references from a specific container. Bug fixes --------- o ADT.Heap The Element class lost track of its position when remove() was used. o Filesystem.Monitor * Improved thread safety and robustness * Inotify-related fixes. o pgsql The new driver in 8.0 suffered from filedescriptor leaks if the database connections were not explicitly close()d. Fixes have been applied which eliminate the filedescriptor leak and also ensure that the filedescriptors are closed the instant the object loses all references. o programs The runtime now attempts to wait for any compilations in progress to complete before complaining about cloning of unfinished programs. This fixes a race-condition when the same program is compiled from different threads. o Runtime Fixed multiple potential NULL-dereferences. o SSL.File Fixed breaking of circular references when the peer terminates the connection. o Standards.URI Support the userinfo field containing '@'. o Stdio.File The second argument to set_buffer() should now work. o Testsuite Updated the SHA3_* testvectors to FIPS 202. Building and installing ----------------------- o Multiple fixes for building on Solaris 11.

4 6

Fixing compilation with --enable-werror
by Chris Angelico 03 Mar '16

03 Mar '16

Currently, 8.1 trunk doesn't build with CONFIGUREARGS=--enable-werror on GCC 5.3.1, due to a couple of small issues. I've pushed fixes to the rosuav/enable-werror branch; can someone please try this on a different system, different compiler, etc, to see if it breaks anything? The three changes are: 1) Add a #include to ensure that a function is available. 2) Enable a block of code that was otherwise restricted to PIKE_DEBUG mode 3) Work around a spurious GCC warning! ChrisA

1 0

Re: Tracking down corruption after exception in GTK signal handler
by Chris Angelico 03 Mar '16

03 Mar '16

On Thu, Mar 3, 2016 at 11:00 PM, Peter Bortas @ Pike developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Try compileing Pike with -fsanitize=address, there's a fairly good > chance that would catch exactly when things start going wrong of we > are talking about any kind of over/under-flow. > While I was poking with this, Grubba pushed a fix that appears to cure the problem (both for my little test case and for the original): bdcd55, using safe_apply_value. Thanks Grubba! Came across a really obscure compilation bug, though. Fun stuff. ChrisA

1 0

Tracking down corruption after exception in GTK signal handler
by Chris Angelico 03 Mar '16

03 Mar '16

int main() { GTK2.setup_gtk(); object btn=GTK2.Button("Raise an exception"); object win=GTK2.Window(0)->add(btn)->show_all(); win->signal_connect("destroy",lambda() {exit(0);}); btn->signal_connect("clicked",lambda() {error("Baboom!\n");}); return -1; } Run this, click the button, then close the window. Pike will segfault. Running a --with-debug Pike under gdb shows that the actual segfault occurs in backend_callback (defined in GTK2/source/global.pre), where it calls into the low end main loop for an iteration. Not immediately helpful. I suspect that something's getting corrupted - maybe in the Pike stack, maybe something gets freed in GTK that should have another reference - when the exception happens. How can I go about tracking this down? Where would I put probes to watch for unexpected changes? ChrisA

4 19

Re: Pike 8.0.182 release candidate
by Stephen R. van den Berg 03 Mar '16

03 Mar '16

Peter Bortas wrote: >o programs > The runtime now attempts to wait for any compilations in progress to > complete before complaining about cloning of unfinished programs. > This fixes a race-condition when the same program is compiled from > different threads. Incidentally: this fix is incomplete. So it fixes some of those race-conditions, but not all of them. -- Stephen.

2 3

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 March 2016