Hi, Something to think about in Christmas/New Year times?
When building mp4h and running the built program on an input file it segfaults in some cases. For example when creating the documentation from mp4h.mp4h during the build. Giving the same command two directory levels higher succeeds! I found out that the end of the environment vector __environ is overwritten/truncated somewhere, removing the null termination. Then a subsequent a call to getenv() makes the program segfault! The problem is a too short resolvedname vector in builtin.c, see bug #653362. The segfault happens by running the test program with a long PWD string, e.g.: cd .../mp4h/mp4h-1.3.1/src mkdir a_very_long_pathname_and_even_longer cd a_very_long_pathname_and_even_longer ../mp4h ../test2.mp4h I'm attaching the stripped-down test2.mp4h file. On GNU/Linux shortening the resolvedname vector from PATH_MAX to 64 results in a stack corruption. This is not nice, but since that vector is allocated on the stack, maybe it is more acceptable than an environment corruption. Anyway, it seems that the realpath() function is not to be trusted with fixed length vectors, unless the size is PATH_MAX (= 4096) according to the man page if it is defined. The preferred way of usage seems to be a resolved_path equal to NULL (or canonicalize_file_name()) or even the lstat() call.
;;; ;;; mp4h.mp4h -- Documentation for mp4h ;;; Copyright 2000-2003, Denis Barbier <barb...@linuxfr.org> ;;; <set-var package=mp4h /> <set-var title="mp4h - Macro Processor for HTML Documents" /> <example> <real-path pathname=<__file__/> /> </example> <example> <date/> <set-var info=<get-file-properties <__file__/> /> /> <date <get-var info[2] /> /> <date time="<get-var info[2] />" format="%Y-%m-%d %H:%M:%S" /> </example>
