I've tried Martin's /etc/localtime with his malaga.dvi file on my system
and had no problems. The localtime file doesn't appear to be corrupt and
this isn't one of those half-hour timezones. I think those are red
herrings. This is probably a new problem that might be unique to the
AMD64 architecture.
There aren't very many ways I can imagine where the patch would corrupt
memory. Possibilities are the call to time() itself, the call to
localtime(), and the call to sprintf() which writes to the variable named
'date_string'. In the unpatched code, the buffer named 'date_string' was
being overrun due to the half-hour time zones. Assuming the AMD64 time()
and localtime() calls work as expected, it's possible the 'date_string'
buffer may still be overrun somehow. Since I don't have AMD64/Debian,
could you, Martin, run a debugger to see what's being written to
'date_string' in the sprintf() call in pdfdoc.c? If not, could you see if
enlarging the date_string buffer has any effect on the problem?
Mark
On Mon, 5 Feb 2007, Frank K?ster wrote:
Date: Mon, 05 Feb 2007 10:18:18 +0100
From: "Frank [iso-8859-1] K?ster" <[EMAIL PROTECTED]>
To: Mark A. Wicks <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], Martin Michlmayr <[EMAIL PROTECTED]>
Subject: Re: Bug#409517: dvipdfm segfault related to /etc/localtime
Hi Mark,
there seems to be a problem with the timezone patch that we applied
recently to our version of dvipdfm: It again segfaults with certain
timezone files. I'm not even sure whether /etc/localtime might not be
corrupted - but still it should give an error and not segfault. On the
other hand, dvipdfm doesn't open localtime, but query it through defined
APIs, well.
Martin Michlmayr <[EMAIL PROTECTED]> wrote:
* Frank K?ster <[EMAIL PROTECTED]> [2007-02-03 21:13]:
Sorry, I have no idea. But I asked because one of the last changes to
dvipdfm was a patch to *prevent* a segfault when used in a timezone with
half-hour offset from UTC. It's in the same source file, but at a
different place than indicated by the trace, and I don't see the
relation ATM. You can look at it at
Reverting this patch (debian/patches/patch-dvipdfm-timezone-crash)
gets rid of my segfault.
So the exact patch that we applied is at
http://svn.debian.org/wsvn/debian-tex/tetex-bin/trunk/debian/patches/patch-dvipdfm-timezone-crash?op=file&rev=0&sc=0
and Martin's complete bug report is at
http://bugs.debian.org/409517
Martin, do you happen to know how tzconfig handles /etc/localtime? On
my sarge system, /etc/localtime is a symlink to a particular file below
/usr/share/zoneinfo/ (to Europe/Zurich), on my sid system it's an
ordinary file.
Is there an easy way to find out which of the preprocessor conditional
branches we're in? I'm speaking of
+#ifdef HAVE_TM_GMTOFF /* Preferred way to get time zone offset */
+ tz_offset = bd_time->tm_gmtoff;
+#else
+#ifdef HAVE_TIMEZONE /* Plan B --- use external variable 'timezone'
+ /* (may not provide correct offset for daylight savings
time) */
+ tz_offset = - timezone;
+#else /* Last resort --- without more information, set offset
to zero */
+ tz_offset = 0l;
+#endif /* HAVE_TIMEZONE */
+#endif /* HAVE_TM_GMTOFF */
The file is compiled with this command:
cc -DHAVE_CONFIG_H -I. -I. -I.. -I./.. -O2 -c pdfdoc.c -o pdfdoc.o
TIA, Frank
--
Dr. Frank K?ster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Z?rich
Debian Developer (teTeX/TeXLive)
