Question about vfprintf hook VM argument (original) (raw)

Thomas Stüfe thomas.stuefe at gmail.com
Tue May 9 06:54:51 UTC 2017

Hi David,

On Mon, May 8, 2017 at 11:25 PM, David Holmes <david.holmes at oracle.com> wrote:

Hi Thomas,

On 8/05/2017 7:29 PM, Thomas Stüfe wrote:

Hi all,

what exactly is the purpose of the FILE* argument in the vfprintf hook? I see your point. :) The vfprinthook is a replacement vfprintf function to be called from jiovfprintf: int jiovfprintf(FILE* f, const char *fmt, valist args) { if (Arguments::vfprintfhook() != NULL) { return Arguments::vfprintfhook()(f, fmt, args); } else { return vfprintf(f, fmt, args); } } so whatever gets passed to jiovfprintf gets passed through to the hook. But ... We had - actually several times already - the problem that our VM was embedded by a customized launcher which used the vfprintf hook to redirect the VM output. If the launcher uses the FILE* handed over by the VM to write to, it must be linked against the same C-Runtime as the VM itself. This is not necessarily a given, especially on Windows: the launcher may link against the debug C-Runtime (compiled with /MDd) wheras the JDK is build with "/MD" and links against the release C-Runtime. Or the launcher may even have been linked statically against the C-Runtime. Or... In my opinion it is not a good idea to hand over C-Runtime internals - be it malloced memory or FILE* pointers - to other binaries which may have been built with different build options. But I do not even understand the point of passing FILE* to the hook? If the point of the hook is to give embedding code the ability to write to somewhere else, why even bother giving it my file pointer? ... I confess I had no idea why this vfprint hook exists, but this somewhat explains it: https://bugs.openjdk.java.net/browse/JDK-4015550 and yes it does suggest that although the FILE* is passed in the expectation is that the function will actually write somewhere else. IIUC the intent was to allow fd's 0,1 and 2 to be re-mapped by the hook to match whatever the embedded app had change System.out/err to. But as fd's were per-dll they couldn't pass through the fd so they passed through the FILE*. But how they expected that to be mapped to stdout/stderr I have no idea. Thanks for looking at this, interesting piece of history!

Well, maybe this was just not that well thought out. Handing the va_list up to the hookee and letting him unwrap it is is also unconventional, but probably does no harm, even when done by a different C-Runtime.

I guess we continue living with it. We have a checklist for potential embedders writing launchers (e.g. not to use the primordial thread on AIX), and will add "Use the same C-Runtime as the JDK on Windows" to the list.

Regards, Thomas

Cheers, David

Thanks & Kind Regards, Thomas

More information about the hotspot-dev mailing list