<br><br><div class="gmail_quote">On Thu, Aug 11, 2011 at 8:32 PM, Ramarren <span dir="ltr"><<a href="mailto:ramarren@gmail.com">ramarren@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">

<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     GLIB_SIZEOF_SIZE_T != GLIB_SIZEOF_LONG || !defined __cplusplus<br>
typedef gsize                           GType;<br>
#else   /* for historic reasons, C++ links against gulong GTypes */<br>
typedef gulong                          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 <<a href="mailto:theotherjimmy@gmail.com">theotherjimmy@gmail.com</a>> wrote:<br>
</div><div><div></div><div class="h5">> I have been prodding the memory fault problem on my 64bit machine ans have<br>
> narrowed it down to one function:<br>
> gtk-list-store-newv<br>
> when called like (gtk-ffi:gtk-list-store-new '(:string :string)) this<br>
> function consistently produces unhandled memory fault errors (at<br>
> #x4000000056 for '(:string :string)) when passed anything that is length 2<br>
> or more or contains strings (the '(:string :string) example is what<br>
> (test-gtk:gtk-demo) calls).<br>
> the type signature looks like a match to the header files on my system.<br>
> for reference I am using sbcl 1.0.50 on Archlinux x86_64 with gtk and sbcl<br>
> compiled 64bit and a fresh (as of an hour ago) pull of cells-gtk3<br>
> from <a href="https://github.com/Ramarren/cells-gtk3.git" target="_blank">https://github.com/Ramarren/cells-gtk3.git</a><br>
> I am happy to help in any way I can and can provide more information if<br>
> needed.<br>
> Thanks for the great library,<br>
> Jimmy<br>
> --<br>
> "Open-source software has fewer bugs because it admits the possibility of<br>
> bugs." Paul Graham<br>
><br>
</div></div><div><div></div><div class="h5">> _______________________________________________<br>
> cells-gtk-devel site list<br>
> <a href="mailto:cells-gtk-devel@common-lisp.net">cells-gtk-devel@common-lisp.net</a><br>
> <a href="http://common-lisp.net/mailman/listinfo/cells-gtk-devel" target="_blank">http://common-lisp.net/mailman/listinfo/cells-gtk-devel</a><br>
><br>
</div></div></blockquote></div><div><br></div>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" .<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>