BTW, that is in gobject.pre.




On Wednesday, March 2, 2016 8:45 PM, Lance Dillon <riffraff169@yahoo.com> wrote:


However:


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);},0);
    btn->signal_connect("clicked",lambda() {error("Baboom!\n");});
    return -1;
}

Adding another parameter of 0 to signal_connect() fixes it.

int signal_connect(string signal, function callback, mixed|void callback_arg,
                   string|void detail,int|void connect_before)
{
...
  get_all_args("signal_connect",args,"%s%*%*.%s%d",&a,&tmp1,&tmp2,&detail,&connect_before);

Matches detail:

...
  if (detail)
    det=g_quark_try_string(detail);
  else
    det=0;
  id=g_signal_connect_closure_by_id(G_OBJECT(THIS->obj),b->signal_id,det,
                                gc,!connect_before);
  pgtk2_pop_n_elems(args);

So maybe something with detail not existing, so det gets an invalid quark at 0?  Perhaps should change to:

if (detail)
  det=g_quark_try_string(detail);
else
  det=g_quark_try_string(0);


Or:

det=g_quark_try_string(detail?detail:0);

I say 0 because if detail is 0, then g_quark_try_string succeeds.  I believe this might be where the error lies.

Could try it and see.



On Wednesday, March 2, 2016 8:37 PM, Lance Dillon <riffraff169@yahoo.com> wrote:


Also happens with me with :

[riffraff@hobbes src]$ pike --version
Pike v8.0 release 1 Copyright © 1994-2013 Linköping University

compiling 8.1 right now, but that is weird.



On Wednesday, March 2, 2016 8:25 PM, Chris Angelico <rosuav@gmail.com> wrote:


On Thu, Mar 3, 2016 at 9:14 AM, Chris Angelico <rosuav@gmail.com> wrote:
> On Thu, Mar 3, 2016 at 9:06 AM, Lance Dillon <riffraff169@yahoo.com> wrote:
>> Guessing that since win and btn go out of scope at end of main(), maybe they
>> get cleaned up?  I usually set things that need to persist into backend past
>> main as global variables, or at least i have in the past.
>
> That part shouldn't be a problem. In the original code that this is
> cut down from, those objects were indeed persisted elsewhere; and the
> GTK signal retains references anyway.
>
> Odd discovery: Now that I'm on my laptop, I can't trigger the
> segfault. That might mean the corruption's still there but just
> doesn't happen to crash anything, or it might mean there's a real and
> significant difference. Both systems are using fairly recent builds of
> Pike 8.1, and updating the laptop to the very latest didn't start the
> segfaults. Strange. But it means I can't do the quick and obvious
> verification you mention until I get home.
>
> ChrisA

Back on my main system, and the tiny tweak of hoisting the
declarations to global doesn't change the crash. And compiling the
latest Pike 8.1 doesn't change anything, either.


ChrisA