Pike-devel March 2016

pike-devel@lists.lysator.liu.se

7 participants
13 discussions

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

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