jimmy brisson | 11 Aug 21:40 2011
Picon

64bit listbox problem

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
<div>
<p>I have been prodding the memory fault problem on my 64bit machine ans have narrowed it down to one function:</p>
<div>gtk-list-store-newv</div>
<div><br></div>
<div>when called like (gtk-ffi:gtk-list-store-new '(:string :string))&nbsp;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).</div>

<div>the type signature looks like a match to the header files on my system.</div>
<div>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&nbsp;<a href="https://github.com/Ramarren/cells-gtk3.git">https://github.com/Ramarren/cells-gtk3.git</a>
</div>

<div>I am happy to help in any way I can and can provide more information if needed.</div>
<div>Thanks for the great library,</div>
<div>Jimmy</div>
<div>-- <br>"Open-source software has fewer bugs because it admits the possibility of bugs." Paul Graham<br>
</div>
</div>
Ramarren | 11 Aug 22:32 2011
Picon

Re: 64bit listbox problem

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
>

jimmy brisson | 11 Aug 22:43 2011
Picon

Re: 64bit listbox problem



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
<div>
<br><br><div class="gmail_quote">On Thu, Aug 11, 2011 at 8:32 PM, Ramarren <span dir="ltr">&lt;<a href="mailto:ramarren <at> gmail.com">ramarren <at> gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">

<div class="im">This probably means that the GType width is wrong for 64 bits, which<br>
is not entirely unexpected since it is defined like this:<br><br>
#if &nbsp; &nbsp; GLIB_SIZEOF_SIZE_T != GLIB_SIZEOF_LONG || !defined __cplusplus<br>
typedef gsize &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; GType;<br>
#else &nbsp; /* for historic reasons, C++ links against gulong GTypes */<br>
typedef gulong &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;GType;<br>
#endif<br><br>
which means it can be either an uint (at least I hope gsize is<br>
consistently uint) or an ulong. On 32 bit machine they are the same,<br>
on 64 bit not. I had assumed that the first branch is the usual and<br>
defined gtype as gsize/uint. An easy fix would be to change<br>
(cffi:defctype gtype gsize) to (cffi:defctype gtype gulong). But that<br>
might break this on some other systems.<br><br>
Since I am not sure how to detect this without invoking the C<br>
compiler, I have now added the change as a controllable feature with<br>
ulong as a default and pushed to the repository. Please test it and<br>
report if it fixes the memory fault.<br><br>
Jakub Higersberger<br><br>
On Thu, Aug 11, 2011 at 9:40 PM, jimmy brisson &lt;<a href="mailto:theotherjimmy <at> gmail.com">theotherjimmy <at> gmail.com</a>&gt; wrote:<br>
</div>
<div>
<div></div>
<div class="h5">&gt; I have been prodding the memory fault problem on my 64bit machine ans have<br>
&gt; narrowed it down to one function:<br>
&gt; gtk-list-store-newv<br>
&gt; when called like (gtk-ffi:gtk-list-store-new '(:string :string))&nbsp;this<br>
&gt; function consistently produces unhandled memory fault errors (at<br>
&gt; #x4000000056 for '(:string :string)) when passed anything that is length 2<br>
&gt; or more or contains strings (the '(:string :string) example is what<br>
&gt; (test-gtk:gtk-demo) calls).<br>
&gt; the type signature looks like a match to the header files on my system.<br>
&gt; for reference I am using sbcl 1.0.50 on Archlinux x86_64 with gtk and sbcl<br>
&gt; compiled 64bit and a fresh (as of an hour ago) pull of cells-gtk3<br>
&gt; from&nbsp;<a href="https://github.com/Ramarren/cells-gtk3.git" target="_blank">https://github.com/Ramarren/cells-gtk3.git</a><br>
&gt; I am happy to help in any way I can and can provide more information if<br>
&gt; needed.<br>
&gt; Thanks for the great library,<br>
&gt; Jimmy<br>
&gt; --<br>
&gt; "Open-source software has fewer bugs because it admits the possibility of<br>
&gt; bugs." Paul Graham<br>
&gt;<br>
</div>
</div>
<div>
<div></div>
<div class="h5">&gt; _______________________________________________<br>
&gt; cells-gtk-devel site list<br>
&gt; <a href="mailto:cells-gtk-devel <at> common-lisp.net">cells-gtk-devel <at> common-lisp.net</a><br>
&gt; <a href="http://common-lisp.net/mailman/listinfo/cells-gtk-devel" target="_blank">http://common-lisp.net/mailman/listinfo/cells-gtk-devel</a><br>
&gt;<br>
</div>
</div>
</blockquote>
</div>
<div><br></div>that seems to have fixed the listbox error, but the same error (including that #x400... value) &nbsp;appears after "query link :tree-selection-predicate cells-store nil" .<div>

I will pull it apart now to look for the source.</div>
<div>thanks,</div>
<div>Jimmy<br><br clear="all"><br>-- <br>"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<br>

"Open-source software has fewer bugs because it admits the possibility of bugs." Paul Graham<br>
</div>
</div>
jimmy brisson | 11 Aug 22:50 2011
Picon

Re: 64bit listbox problem

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
<div>
<p>found this problem, replace stray :int's in the function def with 'gtype's</p>
<div><br></div>
<div>this fixed the last problem, now (test-gtk:gtk-demo runs.</div>
<div>thanks for your help,</div>
<div>Jimmy<br><br><div class="gmail_quote">

On Thu, Aug 11, 2011 at 8:43 PM, jimmy brisson <span dir="ltr">&lt;<a href="mailto:theotherjimmy <at> gmail.com">theotherjimmy <at> gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">

<div>
<div></div>
<div class="h5">
<br><br><div class="gmail_quote">On Thu, Aug 11, 2011 at 8:32 PM, Ramarren <span dir="ltr">&lt;<a href="mailto:ramarren <at> gmail.com" target="_blank">ramarren <at> gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div>This probably means that the GType width is wrong for 64 bits, which<br>
is not entirely unexpected since it is defined like this:<br><br>
#if &nbsp; &nbsp; GLIB_SIZEOF_SIZE_T != GLIB_SIZEOF_LONG || !defined __cplusplus<br>
typedef gsize &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; GType;<br>
#else &nbsp; /* for historic reasons, C++ links against gulong GTypes */<br>
typedef gulong &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;GType;<br>
#endif<br><br>
which means it can be either an uint (at least I hope gsize is<br>
consistently uint) or an ulong. On 32 bit machine they are the same,<br>
on 64 bit not. I had assumed that the first branch is the usual and<br>
defined gtype as gsize/uint. An easy fix would be to change<br>
(cffi:defctype gtype gsize) to (cffi:defctype gtype gulong). But that<br>
might break this on some other systems.<br><br>
Since I am not sure how to detect this without invoking the C<br>
compiler, I have now added the change as a controllable feature with<br>
ulong as a default and pushed to the repository. Please test it and<br>
report if it fixes the memory fault.<br><br>
Jakub Higersberger<br><br>
On Thu, Aug 11, 2011 at 9:40 PM, jimmy brisson &lt;<a href="mailto:theotherjimmy <at> gmail.com" target="_blank">theotherjimmy <at> gmail.com</a>&gt; wrote:<br>
</div>
<div>
<div></div>
<div>&gt; I have been prodding the memory fault problem on my 64bit machine ans have<br>
&gt; narrowed it down to one function:<br>
&gt; gtk-list-store-newv<br>
&gt; when called like (gtk-ffi:gtk-list-store-new '(:string :string))&nbsp;this<br>
&gt; function consistently produces unhandled memory fault errors (at<br>
&gt; #x4000000056 for '(:string :string)) when passed anything that is length 2<br>
&gt; or more or contains strings (the '(:string :string) example is what<br>
&gt; (test-gtk:gtk-demo) calls).<br>
&gt; the type signature looks like a match to the header files on my system.<br>
&gt; for reference I am using sbcl 1.0.50 on Archlinux x86_64 with gtk and sbcl<br>
&gt; compiled 64bit and a fresh (as of an hour ago) pull of cells-gtk3<br>
&gt; from&nbsp;<a href="https://github.com/Ramarren/cells-gtk3.git" target="_blank">https://github.com/Ramarren/cells-gtk3.git</a><br>
&gt; I am happy to help in any way I can and can provide more information if<br>
&gt; needed.<br>
&gt; Thanks for the great library,<br>
&gt; Jimmy<br>
&gt; --<br>
&gt; "Open-source software has fewer bugs because it admits the possibility of<br>
&gt; bugs." Paul Graham<br>
&gt;<br>
</div>
</div>
<div>
<div></div>
<div>&gt; _______________________________________________<br>
&gt; cells-gtk-devel site list<br>
&gt; <a href="mailto:cells-gtk-devel <at> common-lisp.net" target="_blank">cells-gtk-devel <at> common-lisp.net</a><br>
&gt; <a href="http://common-lisp.net/mailman/listinfo/cells-gtk-devel" target="_blank">http://common-lisp.net/mailman/listinfo/cells-gtk-devel</a><br>
&gt;<br>
</div>
</div>
</blockquote>
</div>
<div><br></div>
</div>
</div>that seems to have fixed the listbox error, but the same error (including that #x400... value) &nbsp;appears after "query link :tree-selection-predicate cells-store nil" .<div>

I will pull it apart now to look for the source.</div>
<div>thanks,</div>
<div>Jimmy<br><br clear="all"><br>-- <br>"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<div class="im">

<br>
"Open-source software has fewer bugs because it admits the possibility of bugs." Paul Graham<br>
</div>
</div>
</blockquote>
</div>
<br><br clear="all"><br>-- <br>"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<br>

"Open-source software has fewer bugs because it admits the possibility of bugs." Paul Graham<br>
</div>
</div>
jimmy brisson | 11 Aug 22:51 2011
Picon

Re: 64bit listbox problem

in my hase I forgot to tell you that the function is (defun gtk-tree-store-new ...


sorry 'bout that,
Jimmy

On Thu, Aug 11, 2011 at 8:50 PM, jimmy brisson <theotherjimmy <at> gmail.com> wrote:
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



--
"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
<div>
<p>in my hase I forgot to tell you that the function is (defun gtk-tree-store-new ...</p>
<div><br></div>
<div>sorry 'bout that,</div>
<div>Jimmy<br><br><div class="gmail_quote">On Thu, Aug 11, 2011 at 8:50 PM, jimmy brisson <span dir="ltr">&lt;<a href="mailto:theotherjimmy <at> gmail.com">theotherjimmy <at> gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">found this problem, replace stray :int's in the function def with 'gtype's<div><br></div>
<div>this fixed the last problem, now (test-gtk:gtk-demo runs.</div>

<div>thanks for your help,</div>
<div>Jimmy<div>
<div></div>
<div class="h5">
<br><br><div class="gmail_quote">
On Thu, Aug 11, 2011 at 8:43 PM, jimmy brisson <span dir="ltr">&lt;<a href="mailto:theotherjimmy <at> gmail.com" target="_blank">theotherjimmy <at> gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">

<div>
<div></div>
<div>
<br><br><div class="gmail_quote">On Thu, Aug 11, 2011 at 8:32 PM, Ramarren <span dir="ltr">&lt;<a href="mailto:ramarren <at> gmail.com" target="_blank">ramarren <at> gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div>This probably means that the GType width is wrong for 64 bits, which<br>
is not entirely unexpected since it is defined like this:<br><br>
#if &nbsp; &nbsp; GLIB_SIZEOF_SIZE_T != GLIB_SIZEOF_LONG || !defined __cplusplus<br>
typedef gsize &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; GType;<br>
#else &nbsp; /* for historic reasons, C++ links against gulong GTypes */<br>
typedef gulong &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;GType;<br>
#endif<br><br>
which means it can be either an uint (at least I hope gsize is<br>
consistently uint) or an ulong. On 32 bit machine they are the same,<br>
on 64 bit not. I had assumed that the first branch is the usual and<br>
defined gtype as gsize/uint. An easy fix would be to change<br>
(cffi:defctype gtype gsize) to (cffi:defctype gtype gulong). But that<br>
might break this on some other systems.<br><br>
Since I am not sure how to detect this without invoking the C<br>
compiler, I have now added the change as a controllable feature with<br>
ulong as a default and pushed to the repository. Please test it and<br>
report if it fixes the memory fault.<br><br>
Jakub Higersberger<br><br>
On Thu, Aug 11, 2011 at 9:40 PM, jimmy brisson &lt;<a href="mailto:theotherjimmy <at> gmail.com" target="_blank">theotherjimmy <at> gmail.com</a>&gt; wrote:<br>
</div>
<div>
<div></div>
<div>&gt; I have been prodding the memory fault problem on my 64bit machine ans have<br>
&gt; narrowed it down to one function:<br>
&gt; gtk-list-store-newv<br>
&gt; when called like (gtk-ffi:gtk-list-store-new '(:string :string))&nbsp;this<br>
&gt; function consistently produces unhandled memory fault errors (at<br>
&gt; #x4000000056 for '(:string :string)) when passed anything that is length 2<br>
&gt; or more or contains strings (the '(:string :string) example is what<br>
&gt; (test-gtk:gtk-demo) calls).<br>
&gt; the type signature looks like a match to the header files on my system.<br>
&gt; for reference I am using sbcl 1.0.50 on Archlinux x86_64 with gtk and sbcl<br>
&gt; compiled 64bit and a fresh (as of an hour ago) pull of cells-gtk3<br>
&gt; from&nbsp;<a href="https://github.com/Ramarren/cells-gtk3.git" target="_blank">https://github.com/Ramarren/cells-gtk3.git</a><br>
&gt; I am happy to help in any way I can and can provide more information if<br>
&gt; needed.<br>
&gt; Thanks for the great library,<br>
&gt; Jimmy<br>
&gt; --<br>
&gt; "Open-source software has fewer bugs because it admits the possibility of<br>
&gt; bugs." Paul Graham<br>
&gt;<br>
</div>
</div>
<div>
<div></div>
<div>&gt; _______________________________________________<br>
&gt; cells-gtk-devel site list<br>
&gt; <a href="mailto:cells-gtk-devel <at> common-lisp.net" target="_blank">cells-gtk-devel <at> common-lisp.net</a><br>
&gt; <a href="http://common-lisp.net/mailman/listinfo/cells-gtk-devel" target="_blank">http://common-lisp.net/mailman/listinfo/cells-gtk-devel</a><br>
&gt;<br>
</div>
</div>
</blockquote>
</div>
<div><br></div>
</div>
</div>that seems to have fixed the listbox error, but the same error (including that #x400... value) &nbsp;appears after "query link :tree-selection-predicate cells-store nil" .<div>

I will pull it apart now to look for the source.</div>
<div>thanks,</div>
<div>Jimmy<br><br clear="all"><br>-- <br>"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<div>

<br>
"Open-source software has fewer bugs because it admits the possibility of bugs." Paul Graham<br>
</div>
</div>
</blockquote>
</div>
<br><br clear="all"><br>-- <br>"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<br>

"Open-source software has fewer bugs because it admits the possibility of bugs." Paul Graham<br>
</div>
</div>
</div>
</blockquote>
</div>
<br><br clear="all"><br>-- <br>"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<br>

"Open-source software has fewer bugs because it admits the possibility of bugs." Paul Graham<br>
</div>
</div>
Ramarren | 11 Aug 23:02 2011
Picon

Re: 64bit listbox problem

OK, thanks, I pushed it to the repository.

Jakub Higersberger

On Thu, Aug 11, 2011 at 10:51 PM, jimmy brisson <theotherjimmy <at> gmail.com> wrote:
> in my hase I forgot to tell you that the function is (defun
> gtk-tree-store-new ...
> sorry 'bout that,
> Jimmy
>
> On Thu, Aug 11, 2011 at 8:50 PM, jimmy brisson <theotherjimmy <at> gmail.com>
> wrote:
>>
>> 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
>
>
>
> --
> "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
>

Peter Hildebrandt | 24 Aug 17:14 2011
Picon

Re: 64bit listbox problem

Jakub, Jimmy,

Thanks to both of you for working through this. Glad to see other
people using this library.

Peter

On Thursday, August 11, 2011, Ramarren <ramarren <at> gmail.com> wrote:
> OK, thanks, I pushed it to the repository.
>
> Jakub Higersberger
>
> On Thu, Aug 11, 2011 at 10:51 PM, jimmy brisson <theotherjimmy <at> gmail.com> wrote:
>> in my hase I forgot to tell you that the function is (defun
>> gtk-tree-store-new ...
>> sorry 'bout that,
>> Jimmy
>>
>> On Thu, Aug 11, 2011 at 8:50 PM, jimmy brisson <theotherjimmy <at> gmail.com>
>> wrote:
>>>
>>> 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
>

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

Gmane