This patch to libgcj would let us resurrect the LD_PRELOAD hack. The idea is to remove the "pr13212.so" entry from LD_PRELOAD during libgcj startup, to avoid passing this to sub-processes which may not be prepared for it.
This is quite ugly and, I think, won't be going into upstream libgcj.
Please comment.
Tom
Index: ChangeLog from Tom Tromey tromey@redhat.com
* prims.cc (scrub_ld_preload): New function. (_Jv_RunMain): Call it.
Index: prims.cc =================================================================== --- prims.cc (revision 109835) +++ prims.cc (working copy) @@ -1339,10 +1339,51 @@ return 0; }
+// If the PR 13212 workaround is mentioned in LD_PRELOAD, remove it. +// If we don't remove it, it will be inherited by processes we exec(), +// and this causes problems on some platforms. Note that this is +// purely a hack and will go away once we have a new enough version of +// the GC. +static void +scrub_ld_preload () +{ + char *val = getenv ("LD_PRELOAD"); + if (! val) + return; + + char preload[strlen (val) + 1]; + strcpy (preload, val); + + char result[strlen (preload) + 2]; + result[0] = '\0'; + + char *state = NULL; + for (char *word = strtok_r (preload, " ", &state); + word; + word = strtok_r (NULL, " ", &state)) + { + int len = strlen (word); + if (len >= 11 && ! strcmp (word + len - 11, "/pr13212.so")) + { + // Don't include this one. + } + else + { + strcat (result, word); + strcat (result, " "); + } + } + + setenv ("LD_PRELOAD", result, 1); +} + void _Jv_RunMain (JvVMInitArgs *vm_args, jclass klass, const char *name, int argc, const char **argv, bool is_jar) { + // Make sure LD_PRELOAD is clean before we might exec a process. + scrub_ld_preload (); + #ifndef DISABLE_MAIN_ARGS _Jv_SetArgs (argc, argv); #endif
Tom Tromey writes:
This patch to libgcj would let us resurrect the LD_PRELOAD hack. The idea is to remove the "pr13212.so" entry from LD_PRELOAD during libgcj startup, to avoid passing this to sub-processes which may not be prepared for it.
This is quite ugly and, I think, won't be going into upstream libgcj.
Please comment.
So no process ever inherits the LD_PRELOAD unless it uses libgcj? Sounds right.
Andrew.
"Andrew" == Andrew Haley aph@redhat.com writes:
This patch to libgcj would let us resurrect the LD_PRELOAD hack. The idea is to remove the "pr13212.so" entry from LD_PRELOAD during libgcj startup, to avoid passing this to sub-processes which may not be prepared for it.
Andrew> So no process ever inherits the LD_PRELOAD unless it uses Andrew> libgcj? Sounds right.
The way it works is the 'java' wrapper sets LD_PRELOAD, and libgcj removes this entry. So, only things invoked via 'java' will get the preload.
If that still sounds ok to you I'll send the patch to Jakub for inclusion in the RPM (or on the RH branch, whatever).
Tom
Tom Tromey writes:
"Andrew" == Andrew Haley aph@redhat.com writes:
This patch to libgcj would let us resurrect the LD_PRELOAD hack. The idea is to remove the "pr13212.so" entry from LD_PRELOAD during libgcj startup, to avoid passing this to sub-processes which may not be prepared for it.
Andrew> So no process ever inherits the LD_PRELOAD unless it uses Andrew> libgcj? Sounds right.
The way it works is the 'java' wrapper sets LD_PRELOAD, and libgcj removes this entry. So, only things invoked via 'java' will get the preload.
If that still sounds ok to you I'll send the patch to Jakub for inclusion in the RPM (or on the RH branch, whatever).
OK. I believe that will work for every case I know.
Andrew.
On Wed, 2006-01-25 at 11:56 -0700, Tom Tromey wrote:
If that still sounds ok to you I'll send the patch to Jakub for inclusion in the RPM (or on the RH branch, whatever).
Has anybody updated pr13212.c to handle symbol versioning yet? It's not on my TODO list, although I did ask Jakub for additional info in the bugzilla entry.
AG
Anthony> Has anybody updated pr13212.c to handle symbol versioning Anthony> yet? It's not on my TODO list, although I did ask Jakub for Anthony> additional info in the bugzilla entry.
Not yet. Jakub didn't like the LD_PRELOAD idea, so maybe we'll be going back to putting this in the GC per your earlier patch:
https://www.redhat.com/archives/fedora-devel-java-list/2005-July/msg00009.ht...
That one may require the versioning thing too. I'll take care of this.
Tom
java-devel@lists.fedoraproject.org