On Thu, Aug 11, 2011 at 8:32 PM, Ramarren <ramarren <at> gmail.com> wrote:

This probably means that the GType width is wrong for 64 bits, which
is not entirely unexpected since it is defined like this:

#if     GLIB_SIZEOF_SIZE_T != GLIB_SIZEOF_LONG || !defined __cplusplus
typedef gsize                           GType;
#else   /* for historic reasons, C++ links against gulong GTypes */
typedef gulong                          GType;
#endif

which means it can be either an uint (at least I hope gsize is
consistently uint) or an ulong. On 32 bit machine they are the same,
on 64 bit not. I had assumed that the first branch is the usual and
defined gtype as gsize/uint. An easy fix would be to change
(cffi:defctype gtype gsize) to (cffi:defctype gtype gulong). But that
might break this on some other systems.

Since I am not sure how to detect this without invoking the C
compiler, I have now added the change as a controllable feature with
ulong as a default and pushed to the repository. Please test it and
report if it fixes the memory fault.

Jakub Higersberger

On Thu, Aug 11, 2011 at 9:40 PM, jimmy brisson <theotherjimmy <at> gmail.com> wrote:

> I have been prodding the memory fault problem on my 64bit machine ans have
> narrowed it down to one function:
> gtk-list-store-newv
> when called like (gtk-ffi:gtk-list-store-new '(:string :string)) this
> function consistently produces unhandled memory fault errors (at
> #x4000000056 for '(:string :string)) when passed anything that is length 2
> or more or contains strings (the '(:string :string) example is what
> (test-gtk:gtk-demo) calls).
> the type signature looks like a match to the header files on my system.
> for reference I am using sbcl 1.0.50 on Archlinux x86_64 with gtk and sbcl
> compiled 64bit and a fresh (as of an hour ago) pull of cells-gtk3
> from https://github.com/Ramarren/cells-gtk3.git
> I am happy to help in any way I can and can provide more information if
> needed.
> Thanks for the great library,
> Jimmy
> --
> "Open-source software has fewer bugs because it admits the possibility of
> bugs." Paul Graham
>

> _______________________________________________
> cells-gtk-devel site list
> cells-gtk-devel <at> common-lisp.net
> http://common-lisp.net/mailman/listinfo/cells-gtk-devel
>

that seems to have fixed the listbox error, but the same error (including that #x400... value)  appears after "query link :tree-selection-predicate cells-store nil" .

I will pull it apart now to look for the source.

thanks,

Jimmy


--
"The closed-source world cannot win an evolutionary arms race with open-source communities, who can put orders of magnitude more skilled time into a problem." --Eric Raymond

"Open-source software has fewer bugs because it admits the possibility of bugs." Paul Graham

found this problem, replace stray :int's in the function def with 'gtype's

this fixed the last problem, now (test-gtk:gtk-demo runs.

thanks for your help,

Jimmy

On Thu, Aug 11, 2011 at 8:43 PM, jimmy brisson <theotherjimmy <at> gmail.com> wrote:

On Thu, Aug 11, 2011 at 8:32 PM, Ramarren <ramarren <at> gmail.com> wrote:

This probably means that the GType width is wrong for 64 bits, which
is not entirely unexpected since it is defined like this:

#if     GLIB_SIZEOF_SIZE_T != GLIB_SIZEOF_LONG || !defined __cplusplus
typedef gsize                           GType;
#else   /* for historic reasons, C++ links against gulong GTypes */
typedef gulong                          GType;
#endif

which means it can be either an uint (at least I hope gsize is
consistently uint) or an ulong. On 32 bit machine they are the same,
on 64 bit not. I had assumed that the first branch is the usual and
defined gtype as gsize/uint. An easy fix would be to change
(cffi:defctype gtype gsize) to (cffi:defctype gtype gulong). But that
might break this on some other systems.

Since I am not sure how to detect this without invoking the C
compiler, I have now added the change as a controllable feature with
ulong as a default and pushed to the repository. Please test it and
report if it fixes the memory fault.

Jakub Higersberger

On Thu, Aug 11, 2011 at 9:40 PM, jimmy brisson <theotherjimmy <at> gmail.com> wrote:

> I have been prodding the memory fault problem on my 64bit machine ans have
> narrowed it down to one function:
> gtk-list-store-newv
> when called like (gtk-ffi:gtk-list-store-new '(:string :string)) this
> function consistently produces unhandled memory fault errors (at
> #x4000000056 for '(:string :string)) when passed anything that is length 2
> or more or contains strings (the '(:string :string) example is what
> (test-gtk:gtk-demo) calls).
> the type signature looks like a match to the header files on my system.
> for reference I am using sbcl 1.0.50 on Archlinux x86_64 with gtk and sbcl
> compiled 64bit and a fresh (as of an hour ago) pull of cells-gtk3
> from https://github.com/Ramarren/cells-gtk3.git
> I am happy to help in any way I can and can provide more information if
> needed.
> Thanks for the great library,
> Jimmy
> --
> "Open-source software has fewer bugs because it admits the possibility of
> bugs." Paul Graham
>

> _______________________________________________
> cells-gtk-devel site list
> cells-gtk-devel <at> common-lisp.net
> http://common-lisp.net/mailman/listinfo/cells-gtk-devel
>

that seems to have fixed the listbox error, but the same error (including that #x400... value)  appears after "query link :tree-selection-predicate cells-store nil" .

I will pull it apart now to look for the source.

thanks,

Jimmy


--
"The closed-source world cannot win an evolutionary arms race with open-source communities, who can put orders of magnitude more skilled time into a problem." --Eric Raymond

"Open-source software has fewer bugs because it admits the possibility of bugs." Paul Graham

--
"The closed-source world cannot win an evolutionary arms race with open-source communities, who can put orders of magnitude more skilled time into a problem." --Eric Raymond
"Open-source software has fewer bugs because it admits the possibility of bugs." Paul Graham