On Thu, Mar 3, 2016 at 11:00 PM, Peter Bortas @ Pike developers forum
<10...@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.
>
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.
Usually very low addresses are due to some struct pointer being NULL, so
that accessing a member will result in (almost) null dereference.
So maybe pike sets something to NULL when cleaning up and GTK still
tries to access that later. I have not looked at anything here, just a
wild guess.
arne
On
On Thu, Mar 3, 2016 at 8:53 PM, Arne Goedeke wrote:
> Try compiling --without-machine-code and --with-valgrind, this will get
> rid of most of the false positives.
Thanks - that gets rid of most of the noise.
This seems to be what's happening:
$ sudo apt-get install libglib2.0-0-dbg libgtk2.0-0
Try compiling --without-machine-code and --with-valgrind, this will get
rid of most of the false positives.
arne
On 03/03/16 10:50, Chris Angelico wrote:
> On Thu, Mar 3, 2016 at 7:13 PM, Arne Goedeke wrote:
>> Try running that test with valgrind, it should tell you more reliably
>> what the iss
On Thu, Mar 3, 2016 at 7:13 PM, Arne Goedeke wrote:
> Try running that test with valgrind, it should tell you more reliably
> what the issue is. You will either have to compile pike --with-valgrind
> or use --smc-check=all so that valgrind is able to deal with the
> generated machine code. Another
Try running that test with valgrind, it should tell you more reliably
what the issue is. You will either have to compile pike --with-valgrind
or use --smc-check=all so that valgrind is able to deal with the
generated machine code. Another useful valgrind option is
--track-origin=yes, which will try
Ah well, good, I must have missed that the first time (apparently).
Anyway, I'll put in some debugs (printfs, right) and do some tracing tomorrow
and see what I can narrow down, unless someone else manages to find it before
then.
On Wednesday, March 2, 2016 8:53 PM, Chris Angelico
wrote:
I tried to add the extra parameter to both signal_connect's, but that didn't do
it.
I'll try to troubleshoot more in the morning, I can't really work on it anymore
tonight.
On Wednesday, March 2, 2016 8:53 PM, Lance Dillon
wrote:
Weird, if I don't click the button it works, but if I
Weird, if I don't click the button it works, but if I do click the button, I
get the segfault...
On Wednesday, March 2, 2016 8:50 PM, Lance Dillon
wrote:
Wait I read it wrong.
Sorry, that was all wrong. That is callback_args, which is a required
parameter.
get_all_args(
On Thu, Mar 3, 2016 at 12:50 PM, Lance Dillon wrote:
> Sorry, that was all wrong. That is callback_args, which is a required
> parameter.
>
>
> get_all_args("signal_connect",args,"%s%*%*.%s%d",&a,&tmp1,&tmp2,&detail,&connect_before);
>
> assign_svalue_no_free(&b->cb,tmp1);
> assign_svalue_no_
On Thu, Mar 3, 2016 at 12:45 PM, Lance Dillon 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_conn
Wait I read it wrong.
Sorry, that was all wrong. That is callback_args, which is a required
parameter.
get_all_args("signal_connect",args,"%s%*%*.%s%d",&a,&tmp1,&tmp2,&detail,&connect_before);
assign_svalue_no_free(&b->cb,tmp1);
assign_svalue_no_free(&b->args,tmp2);
So when it t
BTW, that is in gobject.pre.
On Wednesday, March 2, 2016 8:45 PM, Lance Dillon
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)
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 a
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
wrote:
On Thu, Mar 3, 2016 at 9:14 AM, Chris Angelico wrote
On Thu, Mar 3, 2016 at 9:14 AM, Chris Angelico wrote:
> On Thu, Mar 3, 2016 at 9:06 AM, Lance Dillon 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,
On Thu, Mar 3, 2016 at 9:06 AM, Lance Dillon 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 pr
You could try to move those to global, see if it still happens. If not, that's
probably where the problem lies.
On Wednesday, March 2, 2016 5:06 PM, Lance Dillon
wrote:
Guessing that since win and btn go out of scope at end of main(), maybe they
get cleaned up? I usually set things
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.
On Wednesday, March 2, 2016 3:49 PM, Chris Angelico
wrote:
int main()
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
21 matches
Mail list logo
