GNU Smalltalk crashes when calling xcb_create_window via cCall

Hello everybody!

It's me with my incomplete-xcb-binding again...

To create a window with XCB, I have to call the xcb_create_window()
function. It has the following prototype:

xcb_void_cookie_t
xcb_create_window (xcb_connection_t *c,
                   uint8_t           depth,
                   xcb_window_t      wid,
                   xcb_window_t      parent,
                   int16_t           x,
                   int16_t           y,
                   uint16_t          width,
                   uint16_t          height,
                   uint16_t          border_width,
                   uint16_t          _class,
                   xcb_visualid_t    visual,
                   uint32_t          value_mask,
                   const uint32_t   *value_list);

I wrote the following Smalltalk code to call this function:
Xcb class >> createWindow: aConnection depth: aDepth windowId: wID
    parent: parentID x: posX y: poxY width: aWidth height: aHeight
    borderWidth: bWidth class: aClass visual: aVisual valueMask: aMask
    valueList: aList [
        <cCall: 'xcb_create_window' returning: #void args:
            #(#cObject #char #uInt #uInt #short #short #ushort #ushort
#ushort #ushort #uInt #uInt #cObject)>
    ]
(Yes, its ugly)

When I execute it, I get
`--> gst -f xcbroot.st
xcbroot.st:94: Aborted
xcbroot.st:94: Error occurred while not in byte code interpreter!!
/lib/i686/cmov/libc.so.6(abort+0x188)[0xb7cd3d68]
/usr/local/bin/../lib/libgst.so.7[0xb7e76d19]
zsh: abort      gst -f xcbroot.st

If I will write simple wrapper in my library like...

void
gst_xcb_create_window
    (...the same arguments as for xcb_create_window...)
{
    xcb_create_window (...the arguments...);
}

...and if I will use it instead of "native" xcb functions, e.g.

    <cCall: 'gst_xcb_create_window' ...>

everything will work fine. I've found that only two xcb functions need
such wrappers: xcb_create_window and xcb_map_window.

Is it a GNU Smalltalk bug? Why calls to my own library with the same
functions work? Or I have buggy xcb that is can not be bound... All I
want is just to make this world a bit better :)

With best regards,
Dmitry Matveev

P.S. Attachments:
 * gst-crash-gdb.txt - the GDB output (run & bt) when GST crashes
(direct calls to xcb functions). I hope it will be useful
 * xcbroot.st - the "binding"
 * xcb-gst.c - the wrappers

P.P.S `--> uname -a
Linux debian 2.6.26-2-686 #1 SMP Sun Jun 21 04:57:38 UTC 2009 i686 GNU/Linux

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Hi,

Here is the solution without any additional c code ;)

Cheers,
Gwenael

On Tue, 2009-09-29 at 00:38 +0400, Dmitry Matveev wrote:
_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 09/28/2009 10:38 PM, Dmitry Matveev wrote:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb7bb38d0 (LWP 27965)]
> 0xb7e4a34b in _gst_dictionary_add (dictionaryOOP=0x40353818, associationOOP=0x403587e8) at dict.c:1861
> 1861      SET_ASSOCIATION_VALUE (associationOOP, value);

This is expected, SIGSEGV is trapped by GNU Smalltalk for garbage
collection.  At the beginning of every gdb session you should type

handle SIGSEGV noprint

If you do this, you should get a SIGABRT for the crash, which is the
actual important backtrace.

It could be a libffi bug, or a gst bug (gst uses libffi), or anything
else.  But it is interesting no matter where it lies! :-)  Please send
the right backtrace, maybe we can track this down.

BTW, it is possible that you see more (or simply different) problems
than Gwen because different ABIs may specify different ways to return
structures by value.  In particular it looks like you're on 32-bit while
Gwen, AFAIK, works on a 64-bit machine.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Hello,

New gdb log is attacted.
GNU Smalltalk is build from git (2-3 days ago).

Best regards,
Dmitry

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 09/29/2009 09:14 PM, Dmitry Matveev wrote:
> Hello,
>
> New gdb log is attacted.
> GNU Smalltalk is build from git (2-3 days ago).

Thanks, this looks better.  Can you try again with libxcb's debug symbols?

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 09/29/2009 09:14 PM, Dmitry Matveev wrote:
> Hello,
>
> New gdb log is attacted.
> GNU Smalltalk is build from git (2-3 days ago).

Aha, got it.

I tried using gdb to print the stack in xcb_create_window from both the
failing and the succeeding call.

Here is the failing call to xcb_create_window.  We have first the next
stack frame, then the return address, then the arguments (this is
32-bit, which does not pass arguments in registers):

(gdb) p/x *(uint32_t **) $ebp@20
$6 = {0xffffb2a8, 0x427c27, 0x80c92b8, 0x0, 0x4400000, 0x10b, 0x0, 0x0,
   0x96,  0x96, 0xa, 0x1, 0x21, 0x0, 0x0}

Here is the succeeding call to gst_xcb_create_window:

(gdb) p/x *(uint32_t **)$ebp@20
$4 = {0xffffb298, 0x37bc27, 0x80c92b8, 0x0, 0x4600000, 0x10b, 0x0, 0x0,
   0x96, 0x96, 0xa, 0x1, 0x21, 0x0, 0x0, 0xffffb2d8, 0x37ba3e, 0x37bab0,
   0xffffb2c4, 0x34}

This looks the same---correct, since the cCall pragma was the same.

Now here is the succeeding call to xcb_create_window

(gdb) down
#0  0x001946a5 in xcb_create_window () from /usr/lib/libxcb.so.1
(gdb) p/x *(uint32_t **)$ebp@20
$5 = {0xffffb25c, 0x110618, 0xffffb224, 0x80c92b8, 0x0, 0x4600000,
   0x10b, 0x0, 0x0, 0x96, 0x96, 0xa, 0x1, 0x21, 0x0, 0x0, 0x8074540,
   0xffffb2c0, 0xffffb438, 0xe3c3eb22}

Notice the "0xffffb224" after the return address?  That is the place
where the callee can store the return value, which is not a "void" but
an "xcb_void_cookie_t" -- which is a struct.

So, you have to wrap all the function calls of XCB that are asynchronous
(like xcb_create_window and xcb_map_window).  However, note that big
parts of libxcb, in particular these very functions, are automatically
generated from XML, for example:

   <request name="CreateWindow" opcode="1">
     <field type="CARD8" name="depth" />
     <field type="WINDOW" name="wid" />
     <field type="WINDOW" name="parent" />
     <field type="INT16" name="x" />
     <field type="INT16" name="y" />
     <field type="CARD16" name="width" />
     <field type="CARD16" name="height" />
     <field type="CARD16" name="border_width" />
     <field type="CARD16" name="class" />
     <field type="VISUALID" name="visual" />
     <valueparam value-mask-type="CARD32"
                 value-mask-name="value_mask"
                 value-list-name="value_list" />
   </request>

See

http://www.google.com/codesearch/p?hl=en&sa=N&cd=1&ct=rc#9m0-3TEx8PU/trunk/vcf/src/thirdparty/X11/xcb/proto/src/xproto.xml&q=file:xproto.xml

Unfortunately I could not find the generator, also because
cgit.freedesktop.org is down.  But if there is one, generating the XCB
request functions (i.e. not the whole bindings, only the requests) from
GNU Smalltalk may be a viable path.

BTW, your code has a small memory leak.  You can say

   iter := XcbScreenIterator gcNew.

instead of "new".

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Hello!

>2009/9/30, Paolo Bonzini <[hidden email]>:
>
> Notice the "0xffffb224" after the return address?  That is the place
> where the callee can store the return value, which is not a "void" but
> an "xcb_void_cookie_t" -- which is a struct.

Ooops, I should be more attentive...

> http://www.google.com/codesearch/p?hl=en&sa=N&cd=1&ct=rc#9m0-3TEx8PU/trunk/vcf/src/thirdparty/X11/xcb/proto/src/xproto.xml&q=file:xproto.xml

Excellent, I will take it into consideration :)

> BTW, your code has a small memory leak.  You can say
>
>    iter := XcbScreenIterator gcNew.
>
> instead of "new".

Valuable notice, thanks!

Thank you, Gwenael and Paolo, for the help in the resolution of this
problem, now I can sleep easily :)

With best regards,
Dmitry


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 09/30/2009 09:14 PM, Dmitry Matveev wrote:
Found the source: http://cgit.freedesktop.org/xcb/proto/

It even has documentation for the schema :-) at
http://cgit.freedesktop.org/xcb/proto/tree/doc/xml-xcb.txt

You can try using the latest XML pull parser packages in the git tree...
that would really be great.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk