Your message dated Sun, 17 Mar 2013 09:29:38 +0100
with message-id <[email protected]>
and subject line Re: Bug#562178: icedove: does unnecessary seek without error
checking on .signature
has caused the Debian Bug report #562178,
regarding icedove: does unnecessary seek without error checking on .signature
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
562178: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562178
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: icedove
Version: 2.0.0.22-1.1
Severity: normal
If .signature happens to be a named pipe with a program feeding text
into that named pipe, then icedove does *cough* interesting *cough*
things:
[pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
[pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
[pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
[pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
[pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
[pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
[pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
[pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
[pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
[pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
[pid 20697] lseek(47, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
Error checking is good, mmmkay? Reading a .signature file ought not
be any more complicated that while (!eof) { sig+=readline }
Playing around with seek when unnecessary seems just silly (as well as
not very UNIX like).
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages icedove depends on:
ii debianutils 3.2.2 Miscellaneous utilities specific t
ii fontconfig 2.6.0-4 generic font configuration library
ii libatk1.0-0 1.28.0-1 The ATK accessibility toolkit
ii libc6 2.10.2-2 GNU C Library: Shared libraries
ii libcairo2 1.8.8-2 The Cairo 2D vector graphics libra
ii libfontconfig1 2.6.0-4 generic font configuration library
ii libfreetype6 2.3.11-1 FreeType 2 font engine, shared lib
ii libgcc1 1:4.4.2-3 GCC support library
ii libglib2.0-0 2.22.2-2 The GLib library of C routines
ii libgtk2.0-0 2.18.3-1 The GTK+ graphical user interface
ii libhunspell-1.2-0 1.2.8-5 spell checker and morphological an
ii libjpeg62 6b-15 The Independent JPEG Group's JPEG
ii libnspr4-0d 4.8.2-1 NetScape Portable Runtime Library
ii libnss3-1d 3.12.4-1 Network Security Service libraries
ii libpango1.0-0 1.26.1-1 Layout and rendering of internatio
ii libpng12-0 1.2.40-1 PNG library - runtime
ii libstdc++6 4.4.2-3 The GNU Standard C++ Library v3
ii libx11-6 2:1.3.2-1 X11 client-side library
ii libxft2 2.1.13-3 FreeType-based font drawing librar
ii libxinerama1 2:1.0.3-2 X11 Xinerama extension library
ii libxrender1 1:0.9.5-1 X Rendering Extension client libra
ii libxt6 1:1.0.7-1 X11 toolkit intrinsics library
ii psmisc 22.8-1 utilities that use the proc file s
ii zlib1g 1:1.2.3.3.dfsg-15 compression library - runtime
icedove recommends no packages.
Versions of packages icedove suggests:
pn icedove-gnome-support <none> (no description available)
ii latex-xft-fonts 1.6.4-1 TrueType versions of some TeX font
ii libthai0 0.1.12-1 Thai language support library
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 10.0.12-1
Hello Tim,
Am 16.03.2013 08:48, schrieb Tim Connors:
It isn't broken in the same way - now it opens and reads the file twice,
before discarding the text:
29581 stat("/home/tconnors/.signature1", {st_mode=S_IFIFO|0644, st_size=0,
...}) = 0
29581 open("/home/tconnors/.signature1", O_RDONLY) = 47
29581 stat("/home/tconnors/.signature1", {st_mode=S_IFIFO|0644, st_size=0,
...}) = 0
29581 close(47) = 0
29581 stat("/home/tconnors/.signature1", {st_mode=S_IFIFO|0644, st_size=0,
...}) = 0
29581 open("/home/tconnors/.signature1", O_RDONLY) = 47
29581 read(47, "TimC\nIf you tried to understand "..., 4096) = 140
29581 read(47, "", 4096) = 0
29581 close(47) = 0
So yep, still broken, but at least not quite as broken. Progress!
No, I would say no more broken. But yes, I agree, the multi open and
close of this descriptor is not a smart way of doing. Yesterday in my
short time I tried to find out there this open/close thing happen but
without success. Upstream in the Bugzilla of Mozilla I haven't found a
open bug for this behavior. So if you found a valid bug for this or you
willing open a new request inside Bugzilla just do it please. But, in
fact the original bug isn't existing anymore, I will close this bug.
Please feel free to open a new bug report, but we don't willing spend
much time on it, this behavior is "just" cosmetic thing and doesn't
disrupt the functionality of Icedove. If you can triage the reason for
this any help is appreciated.
--
Regards
Carsten
--- End Message ---
