The initial failure was observed on `meld` against recently released
`libffi-3.4-rc1`. There `meld` crashes as:
```
$ meld
Segmentation fault (core dumped)
$ gdb --args /usr/bin/python3.9 /usr/bin/meld
(gdb) run
...
Thread 1 "python3.9" received signal SIGSEGV, Segmentation fault.
0x00007fffe9ac1ae8 in g_callable_info_free_closure (
callable_info=0x555555d45990, closure=0x7fffe9e70c20)
at ../gobject-introspection-1.68.0/girepository/girffi.c:428
428 g_free (wrapper->ffi_closure.cif->arg_types);
(gdb) bt
callable_info=0x555555d45990, closure=0x7fffe9e70c20)
at ../gobject-introspection-1.68.0/girepository/girffi.c:428
data=0x555555d252d0)
at ../pygobject-3.40.1/gi/pygi-closure.c:635
...
```
The bug here is in type mismatch between expected return value of
`g_callable_info_prepare_closure()` and actual value (executable
code pointer):
```c
ffi_closure * g_callable_info_prepare_closure(...) {
gpointer exec_ptr;
...
status = ffi_prep_closure_loc (&closure->ffi_closure, cif, callback, user_data, exec_ptr);
return exec_ptr;
}
```
Note: `exec_ptr` is a code pointer that could be directly executed by
caller, like `((rt (*)(a1,a2))exec_ptr)(1,2);` It should never be wrapped
into an `ffi_closure*`, which is normally called via `ffi_call(closure, ...)`.
We see the problem when we try to free direct code pointer instead of
`ffi_closure()` as starting from libffi-3.4 executable trampoline and
`ffi_closure()` don't necessarily live in the same block:
9ba559217b
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
In case the surrounding code handles missing cases break, otherwise add
a g_assert_not_reached().
The generated parser code triggers this as well, so disable it there only.
- require GTK-Doc 1.19
- remove sgml mode
- automatically generate gi.types (needs GTK-Doc 1.19)
- fix https://bugzilla.gnome.org/show_bug.cgi?id=700025
[WIP] - rearange sections a bit
[WIP] - add gi-building, gi-programming sections
[WIP] - mark missing docs with TODO, which is only marginaly
better than nothing but at least can be grepped :)
https://bugzilla.gnome.org/show_bug.cgi?id=571648
Namely, those that are methods and those that throw GErrors.
We have very similar code in two places that calculate arg lengths and
argument types to stick into libffi. Merge, clean up, and correct both.
https://bugzilla.gnome.org/show_bug.cgi?id=673805
To call a function dynamically using ffi, the caller
first has to tell ffi the size of all the input arguments
of the function. On little endian architectures (like x86_64)
specifying a size that's too large will happen to work because
of how the bits are laid out in memory. On big endian architectures,
however, specifying the wrong size can lead to reading the wrong
bits.
The function g_type_info_get_ffi_type maps input giargument types to
specific sizes. It was assuming enums were word (pointer) sized; in
fact they can be in theory any size (1,2,4,8 bytes), but in practice
in introspection (via GIArgument) as well as GValue we're limited to 4
byte enums.
This commit fixes PPC64 (big endian, 64 bit).
Signed-off-by: Colin Walters <walters@verbum.org>
https://bugzilla.gnome.org/show_bug.cgi?id=665150
Previously we had both e.g. GI_TYPE_TAG_LONG and GI_TYPE_TAG_INT64,
but in fact the typelib is already machine-specific, so it makes sense
to just encode this as a fixed type. The .gir remains abstract.
We also remove size_t from the typelib; one would never want to treat
it differently than an integer.
time_t is removed as well; while bindings like gjs had special handling
to turn it into e.g. a JS Date object, I don't think we should encourage
people to use these POSIX types in their API. Use GTimeVal or the like
instead.
Because the typelib is now really machine-specific, we need to remove
the -expected.tgirs from git. (We could potentially add a check
which wasn't just a literal diff later)
https://bugzilla.gnome.org/show_bug.cgi?id=623774
This restores the reverted-commit ed8634d:
Author: Dan Winship <danw@gnome.org>
Date: Mon Apr 5 14:05:52 2010 -0400
g_callable_info_prepare_closure: handle mmap permissions error
When SELinux or similar is active, a process may not be able to mmap()
a segment that is both writable and executable, which would causing
g_callable_info_prepare_closure() to fail. Libffi has a workaround for
this problem though (it maps the same non-anonymous region twice, once
writable and once executable, and returns two separate pointers to
it), so use that.
But with an added fix, when using ffi_closure_alloc(), we need to use
ffi_prep_closure_loc() so we can pass in the executable address of the
trampoline separately from the writable address, rather than the
deprecated ffi_prep_closure().
https://bugzilla.gnome.org/show_bug.cgi?id=615105
This reverts commit ed8634ddf73a56cb1935fd87254b3c6c04352893.
This commit caused crashes in gjs/gnome-shell, which we're still trying
to track down. See: http://bugzilla.gnome.org/615078
When SELinux or similar is active, a process may not be able to mmap()
a segment that is both writable and executable, which would causing
g_callable_info_prepare_closure() to fail. Libffi has a workaround for
this problem though (it maps the same non-anonymous region twice, once
writable and once executable, and returns two separate pointers to
it), so use that.
https://bugzilla.gnome.org/show_bug.cgi?id=614903
Rather than having bindings use g_function_info_invoke, which is basically
a toy/demo API, export a convenience utility function which takes the introspection
information and sets up things we need to pass to libffi.
Then invocation can be done directly to libffi by a binding.
As part of this work, remove some (unused by gjs) public functions from the
girffi API, and instead export a function to map to libffi which can work
semi-correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=604074
Due to a missing header, gobject-introspection fails to compile on OpenBSD.
And only due to headers-including-headers practice this doesn't blow up on
many other platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=596226
Add type tags for short and ushort, plus all of the requisite code needed
to utilize them in libgirepository.
Add support in the scanner's AST files.
Add test functions to the everything library and the expected gir file.
gtypelib.c constant validation fixed by Colin Walters <walters@verbum.org>
Extract a function to convert GITypeTag to ffi_type from the internals
of ginvoke.c. This will be useful in figure out structure alignment.
Also fix handling of gsize and time_t to be portable. (Add a check
to configure.ac to figure out the width of time_t.)
svn path=/trunk/; revision=873
