On 2013-03-08, Sebastian Ramacher wrote: > On 2013-03-06 20:02:16, Antoine Beaupré wrote: >> So I ran the patched version under valgrind, which I am not familiar >> with at all so YMMV. >> >> I attach the output. >> >> Basically, what I see is one of those: >> >> ==3852== Conditional jump or move depends on uninitialised value(s) >> ==3852== Use of uninitialised value of size 8 >> ==3852== Syscall param rt_sigaction(act->sa_mask) points to uninitialised >> byte(s) >> >> This seems consistent with the original report of problems with the >> signal handler, in general, but I haven't dug much deeper yet. > > Those valgrind warnings can be fixed quite easily. valgrind is > complaining because some members of ttyclock malloc'd in main and > sigaction in init are read before they were initialized. For example, in > line 70 it is checked if ttyclock->geo.x is zero, but ttyclock->geo.x > has no well defined value at this point. > > To silence the warnings it should be enough to just run memset over the > allocated memory: once for ttyclock after the first malloc in main and > once for sig in init.
So it turns out that there's a new upstream at github that worked a bit
on the code, at the very least to cleanup the use-after-free
problems. But there are other changes on that branch, including
providing a manpage and fixing the readme, so that may not be fit for a
release... Here's the diffstat:
Makefile | 18 +++++++++++++-----
README | 24 ++++++++++++++----------
tty-clock.1 | 121
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ttyclock.c | 93
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------
ttyclock.h | 10 ++++++++++
5 files changed, 240 insertions(+), 26 deletions(-)
But almost all warnings are fixed in that 2.0 release out there, only
those remain:
==14964== Syscall param rt_sigaction(act->sa_mask) points to uninitialised
byte(s)
==14964== at 0x52AC60E: __libc_sigaction (sigaction.c:65)
==14964== by 0x401A6B: init (ttyclock.c:75)
==14964== by 0x4033D5: main (ttyclock.c:593)
==14964== Address 0x7fefffc18 is on thread 1's stack
==14964==
==14964== Syscall param rt_sigaction(act->sa_mask) points to uninitialised
byte(s)
==14964== at 0x52AC60E: __libc_sigaction (sigaction.c:65)
==14964== by 0x401A84: init (ttyclock.c:76)
==14964== by 0x4033D5: main (ttyclock.c:593)
==14964== Address 0x7fefffc18 is on thread 1's stack
==14964==
==14964== Syscall param rt_sigaction(act->sa_mask) points to uninitialised
byte(s)
==14964== at 0x52AC60E: __libc_sigaction (sigaction.c:65)
==14964== by 0x401A9D: init (ttyclock.c:77)
==14964== by 0x4033D5: main (ttyclock.c:593)
==14964== Address 0x7fefffc18 is on thread 1's stack
==14964==
==14964== Syscall param rt_sigaction(act->sa_mask) points to uninitialised
byte(s)
==14964== at 0x52AC60E: __libc_sigaction (sigaction.c:65)
==14964== by 0x401AB6: init (ttyclock.c:78)
==14964== by 0x4033D5: main (ttyclock.c:593)
==14964== Address 0x7fefffc18 is on thread 1's stack
I really wonder what to do at this point. I can certainly upload the 2.0
version to experimental to allow people to test this more thoroughly
(but then again, it's just once C file, easy enough to test). But I
don't feel those bugs are serious enough to block the Wheezy release. It
doesn't seem those issues are critical enough to justify the "serious"
severity, but maybe I am wrong.
Would I would like to do is to upload a 1.1-2 with Bremner's patch and
then request an unblock and close this bug report.
Another option would be to upload upload 2.0-1 to sid and try to unblock
*that*, but I feel this would take too much time from the release
managers.
Any opinions on the way to go forward here? Are the signal handlers
warnings important enough to block the wheezy release?
Also note that I have forwarded to our new upstream, we'll see what
happens there..
Thanks for the feedback,
A.
--
Information is not knowledge
Knowledge is not wisdom
Wisdom is not truth
- Frank Zappa
pgp9yE8w7LqOE.pgp
Description: PGP signature
