This patch fixes a double free error due to a pointer being freed and
then not nulled out.
It appears this is corrupting memory on MacOS as the `/proc` file system
is not available and therefore multiple errors are returned.
Fixes:
(process:54873): GLib-WARNING **: 23:09:25.976: GError set over the top of
a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL
before it's set.
The overwriting error message was: Error opening file /proc/self/maps: No
such file or directory
_br_find_exe: (NULL)gimp-console(54873,0x100957e00) malloc: *** error for
object 0x103f09e80: pointer being freed was not allocated
gimp-console(54873,0x100957e00) malloc: *** set a breakpoint in
malloc_error_break to debug
While testing the relocatable code paths, I realized that
_br_find_exe_for_symbol() was always returning NULL. The reason is that
our code looking at /proc/self/maps was expecting that the searched
pointer would be in a "r-xp" memory region. On my machine though, it was
in a "r--p" region.
Maybe in some cases or some older kernel, the "r-xp" permission is/was
right, I have no idea, so now let's just not make any assumption on the
region's permission, where we expect to find our static string, i.e.
let's not do any test on the region permission anymore.
Even though it is set by Linux's limits.h and apparently by other OSes
too, it seems this macro is mostly bogus. On many systems, the actual
allowed max size of paths is much higher.
On Hurd, they don't even define the macro as there is no upper limit.
See MR !424.
This commit replaces two usages of PATH_MAX:
- readlink() by g_file_read_link(). I checked the GLib implementation
and could confirm it will do the proper thing, which is progressively
incrementing their buffer allocation in a loop until the buffer is big
enough to contain the symbolic link contents. Hence no need to rely on
a bogus macro which is not the actual max.
- fgets() by g_data_input_stream_read_line() which also dynamically
allocates the returned buffer, and also properly removes the newline
and adds a NUL byte (hence simpler code).
Additionally I loop through the lines of /proc/self/maps until I find
the first "r-xp" pathname. Indeed the current code was assuming that the
first line was always right. Yet on my OS at least, the first line was
GIMP executable with "r--p" permission, hence the test would fail. The
second line had the right permission. So let's assume that we want the
first executable path, looping through each line.
Older --enable-binreloc configure option had basically the same purpose
as the newer --enable-relocatable-bundle, though the old binreloc was
only used for gimpenv.c code.
As a consequence, commit 10ce702188 was still not working fine since
gimp_installation_directory_file() also need binreloc enabled (to be
actually relocatable).
Let's get rid of this whole mess, by implying we want binreloc code to
be used when --enable-relocatable-bundle is ON. We don't need the
m4macros anymore, since AM_BINRELOC was basically just checking that
`/proc/self/maps` was present. But anyway being present at compile time
does not mean it will be at runtime (nor the opposite). So this test is
not that useful. The binreloc code will anyway fallback gracefully to
the non-binreloc code (i.e. trying to use build-time install paths) if
the procfs is lacking at runtime.
by removing all but the toplevel prefix getter from gimpreloc.c It was
1) confusing 2) sometimes trying to subsitute the runtime prefix twice
and 3) sometimes ignoring configure-given directories within the
configure-prefix. This should all be fixed now, and done in one less
place.
2008-09-04 Michael Natterer <mitch@gimp.org>
* libgimpbase/gimpreloc.c (set_gerror): made the error_message
variable const.
svn path=/trunk/; revision=26856
2005-12-14 Sven Neumann <sven@gimp.org>
* libgimpbase/Makefile.am
* libgimpbase/libgimpbase-docs.sgml
* libgimpbase/libgimpbase-sections.txt: do not generate API docs
for the private wire protocol API.
* libgimp/libgimp-sections.txt: added new path API.
* libgimpbase/tmpl/gimpprotocol.sgml
* libgimpbase/tmpl/gimpwire.sgml: removed from CVS.
* libgimp/tmpl/gimppaths.sgml
* libgimpbase/tmpl/gimpenv.sgml: regenerated.
2005-11-06 Sven Neumann <sven@gimp.org>
Added support for binary relocation by means of binreloc, largely
based on a patch by Hongli Lai:
* m4macros/Makefile.am
* m4macros/binreloc.m4: new file providing a macro to check for
binreloc support.
* acinclude.m4
* configure.in: use the macro.
* libgimpbase/Makefile.am
* libgimpbase/gimpreloc.[ch]: new files providing binreloc support
on Linux.
* libgimpbase/gimpenv.[ch]: use binreloc, provide a function to
initialize the environment machinery.
* libgimpbase/gimpbase.def: updated.
* app/Makefile.am: fiddle with the LDFLAGS for binreloc.
* app/main.c (main): gimp_env_init(FALSE).
* libgimp/gimp.c (gimp_main): gimp_env_init(TRUE).
Lukas Oberhuber