Bug#448418: radioclkd segfaults on amd64
Mark Scott wrote:
Seems I spoke too soon. While the segfault was prevented in test mode
by applying Paul's patch, one occurred at a different place when not
running in test mode. The backtrace doesn't look that helpful -
presumably the ?? in non-radioclkd code indicates library calls for
which debugging info isn't available? The binary used is one compiled
with the patch applied.
Core was generated by `/usr/sbin/radioclkd ttyS0'.
Program terminated with signal 11, Segmentation fault.
#0 0xf52508b3 in ?? ()
(gdb) backtrace
#0 0xf52508b3 in ?? ()
#1 0x08cb08d6 in ?? ()
#2 0xf8500963 in ?? ()
#3 0x0f8e098e in ?? ()
#4 0xf34a09cc in ?? ()
#5 0xe0c80a71 in ?? ()
#6 0xfdf803b6e03a in ?? ()
#7 0xfc6a0ef2 in ?? ()
#8 0x2ba81128 in ?? ()
#9 0x40061128 in ?? ()
#10 0xf5df15b2 in ?? ()
#11 0x07b02c34 in ?? ()
#12 0x3053 in ?? ()
#13 0x4006 in ?? ()
#14 0x4006 in ?? ()
#15 0x00400e1b in _init ()
#16 0x00402010 in ProcessTimeCode (c=0xb7606fd, radio=value
optimized out) at radioclkd.c:709
#17 0x7fffeef10cb8 in ?? ()
#18 0x0002 in ?? ()
#19 0x004024e0 in ProcessStatusChange () at radioclkd.c:845
#20 0x in ?? ()
Line 709 in the patched source is:
if (CalculatePPSAverage(c, average)0) {
and line 845 is:
c-correct = 0;
(which seems strange - how can that lead, 3 frames later, to line 845?).
Commenting out the if block surrounding the call to CalculatePPSAverage
on line 709 and always using the else block instead prevents the
segfault. The preceding comment if possible use an averaged offset
suggests this is OK (but perhaps less accurate or less efficient? I'm
making changes now without understanding the implications...).
I guess the problem is in the libc qsort call, I pass in an array of
timediff which is int's but tell qsort that it is of size long. Not a
problem on an ia32 machine as the two are the same size. However if they
are different it will cause a problem.
JAB.
--
Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk
Northumberland, United Kingdom. Tel: +44 1661-832195
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448418: radioclkd segfaults on amd64
On Mon, 2007-10-29 at 00:24 +, Paul Martin wrote: On Sun, Oct 28, 2007 at 10:07:59PM +, Mark Scott wrote: I have a home-built radio clock receiver for the DCF77 time signal that has been working fine for a year while attached to an i386 machine. I moved it to an amd64 machine and find that radioclkd segfaults when decoding the DCF77 signal. radioclkd tries a binary chop across the full range of time_t, starting with the middle value that the type can hold. Unfortunately, gmtime() doesn't like handing the value 0x4000 What happens if you add the following line at line 213 in radioclkd.c? /* calculate the number of magnitude bits in a time_t */ for (bits=0,timep=1;timep0;bits++,timep=1) ; + if (bits 48) bits = 48; /* if time_t is signed, 0 is the median value else 1bits is median */ timep = (timep0) ? 0 : ((time_t) 1bits); This limits the range of time_t values to years 1970 to 8921556. If we're still using longwave radio clocks in eight million years time, we've got major problems. Given that all the longwave radio clocks only broadcast two digit year numbers, eight million years is not a problem. However surely this is a libc bug and not a radioclkd bug. It is not in my opinion appropriate in an open source system to patch radioclkd to work around a bug in libc. We have access to the source of libc and the gmtime function should be fixed in libc. It has the benefit of fixing bugs in other programs potentially before they even manifest themselves. I guess the problem is that libc is not 64bit clean :-( JAB. -- Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk Northumberland, United Kingdom. Tel: +44 1661-832195 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448418: radioclkd segfaults on amd64
Paul Martin wrote: On Sun, Oct 28, 2007 at 10:07:59PM +, Mark Scott wrote: I have a home-built radio clock receiver for the DCF77 time signal that has been working fine for a year while attached to an i386 machine. I moved it to an amd64 machine and find that radioclkd segfaults when decoding the DCF77 signal. I rebuilt the binary package locally to preserve debug info, and attach the executable and a core file. Looks like it's not 64-bit clean. I have an amd64 machine of my own, but never connected my MSF receiver to it. Time for some digging. I guess the UTCtime function is the culprit. The algorithm (though not the code) was lifted from the mktime routine in libntp. I would check a current version of this against UTCtime. You could also test by replacing UTCtime with mktime from libc, and setting the timezone to UTC. If that makes it go away it is definitely the problem. I don't have any 64bit machines that I can hook a receiver up to, to test. All the ones I have access to are either running in 32bit mode or are servers that I am not going to mess with. JAB. -- Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk Northumberland, United Kingdom. Tel: +44 1661-832195 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#153070: I need some advice on Bug #153070
[EMAIL PROTECTED] said: It is obvious that the way the program is behaving the bug report is they it is programmed to behave. I would like to know if there is a better way to handle this. It is a bogus bug report, and probably stems from a lack of understanding of exactly what hotkey does. In the first instance there should only ever be one copy of hotkey running. The code makes sure that this is the case. You don't run two dhcp servers, or two ftp servers etc. and you will find similar code in these programs as well. As it was designed the hotkey program should be started with the X server, and I have it started automatically by GDM at login. It probably should be restructured to run as a demon. In the second instance a lot of people have the mistaken belief that hotkey actually makes the changes to things like speaker volume, power-up mode etc. For the class of Toshiba laptop it was written what actually happens is that the Fn combinations make the changes regardless of whether hotkeys is running or not. What hotkey does is report those changes in a user friendly way in an manner identical to the old Toshiba MaxTime program. My understanding is that for more recent models the hotkey program itself needs to detect the key-presses and make the changes. JAB. -- Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk Northumberland, United Kingdom. Tel: +44 1661-832195 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#153070:
[EMAIL PROTECTED] said: The problem is that the KILL(2) call is used to check to see if a process exists at the specified PID. The default action for SIGUSR1 is to kill the targeted process. Thus the original process dies, and the new process exits. The propper thing to do is to use kill(pid,0), which just checks if a process exists with that pid without actually signaling it. This is standard behavoir, for this type of thing. The bug is not that the second hotkey fails to start, but rather that the attempt to start the seccond hotkey kills the first and then the second exits. Hum, I could have sworn that it did not used do this, and there should be a signal(SIGUSR1, SIG_IGN); line in there to stop the first hotkey dieing. If you look in wmtuxtime you will see such a line. Stupid thing is if I now role up an update to toshutils, it won't be acceptable for stable because it is new upstream version, despite being just bug fixes :( JAB. -- Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk Northumberland, United Kingdom. Tel: +44 1661-832195 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
