An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20080701/3140c7d2/attachment.htm
On Tue, Jul 1, 2008 at 10:04 AM, Ercan Istek <ercan at eryaz.net> wrote:> > Jul 1 11:56:46 ginning upsd[10590]: Can't connect to UPS [tuncmatik] > (megatec-tuncmatik): Connection refused > > Jul 1 11:56:46 ginning upsd[10590]: Data for UPS [tuncmatik] is stale - > check driver > > Jul 1 11:56:46 ginning kernel: megatec[21553]: segfault at 100 ip 00d32216 > sp bffb05f0 error 4 in libgcc_s-4.3.0-20080428.so.1[d2b000+d000] > > What is the problem ?What version of NUT, distribution, etc...? -- Carlos Rodrigues
On Tue, Jul 1, 2008 at 2:22 PM, Ercan Istek <ercan at eryaz.net> wrote:> Hello Carlos, > > nut-client-2.2.2-1.fc9.i386 > > nut-2.2.2-1.fc9.i386 > > I am using Fedora 9 > > Linux ginning 2.6.25.4-30.fc9.i686 #1 SMP Wed May 21 18:12:35 EDT 2008 i686 > i686 i386 GNU/LinuxIs the problem reproducible? How to reproduce it? Does it happen when the driver starts? PS: please keep the list CC:ed, thanks. -- Carlos Rodrigues
On Tue, Jul 1, 2008 at 2:47 PM, Ercan Istek <ercan at eryaz.net> wrote:> Hello Carlos, > > it occur 7-8 hour after i start nut. > > megatec binary dies.Without more information (a stack trace or something), it's kind of difficult to find the problem. It can be a megatec issue, or an issue with the driver host. PS: Please keep the list CC:ed. -- Carlos Rodrigues
Like I said, this may be a problem with megatec, or it may not, so please CC: the NUT mailing-list when you reply. Please run the driver with -DDD at least. Does it terminate in the same place everytime? Rebuilding the driver with debugging symbols on and run it through valgrind would be useful too. On Tue, Jul 1, 2008 at 4:13 PM, Ercan Istek <ercan at eryaz.net> wrote:> Hello Carlos, > > Asking for UPS status [Q1]... > > Q1 => OK [(214.5 214.5 220.1 030 49.9 2.22 41.5 00000000] > > Calculated battery charge: 100.0% > > Asking for UPS status [Q1]... > > Q1 => OK [(214.5 214.5 220.1 030 49.9 2.22 41.5 0000000000000000] > > Calculated battery charge: 100.0% > > *** stack smashing detected ***: megatec terminated > > ======= Backtrace: ========> > /lib/libc.so.6(__fortify_fail+0x48)[0x9b6ce8] > > /lib/libc.so.6(__fortify_fail+0x0)[0x9b6ca0] > > megatec[0x804a71a] > > megatec[0x804d250] > > [0x871abe8] > > ======= Memory map: =======> > 00110000-00111000 r-xp 00110000 00:00 0 [vdso] > > 00111000-0011b000 r-xp 00000000 08:01 15467217 /lib/libnss_files-2.8.so > > 0011b000-0011c000 r--p 0000a000 08:01 15467217 /lib/libnss_files-2.8.so > > 0011c000-0011d000 rw-p 0000b000 08:01 15467217 /lib/libnss_files-2.8.so > > 008a0000-008bc000 r-xp 00000000 08:01 15826946 /lib/ld-2.8.so > > 008bc000-008bd000 r--p 0001c000 08:01 15826946 /lib/ld-2.8.so > > 008bd000-008be000 rw-p 0001d000 08:01 15826946 /lib/ld-2.8.so > > 008c0000-00a23000 r-xp 00000000 08:01 15826953 /lib/libc-2.8.so > > 00a23000-00a25000 r--p 00163000 08:01 15826953 /lib/libc-2.8.so > > 00a25000-00a26000 rw-p 00165000 08:01 15826953 /lib/libc-2.8.so > > 00a26000-00a29000 rw-p 00a26000 00:00 0 > > 00d2b000-00d38000 r-xp 00000000 08:01 15826975 > /lib/libgcc_s-4.3.0-20080428.so.1 > > 00d38000-00d39000 rw-p 0000c000 08:01 15826975 > /lib/libgcc_s-4.3.0-20080428.so.1 > > 08048000-08054000 r-xp 00000000 08:01 17236226 /sbin/megatec > > 08054000-08055000 rw-p 0000c000 08:01 17236226 /sbin/megatec > > 08719000-0873a000 rw-p 08719000 00:00 0 [heap] > > b7fbc000-b7fbe000 rw-p b7fbc000 00:00 0 > > b7fd1000-b7fd2000 rw-p b7fd1000 00:00 0 > > bf8bc000-bf8d1000 rw-p bffeb000 00:00 0 [stack] > > Aborted > > [root at ginning ~]# > > [root at ginning ~]# > > Broadcast message from nut (Tue Jul 1 18:07:45 2008): > > Communications with UPS tuncmatik at 192.168.1.2 lost > > > Tuesday, July 1, 2008, 4:58:39 PM, you wrote: > >> On Tue, Jul 1, 2008 at 2:47 PM, Ercan Istek <ercan at eryaz.net> wrote: > >>> Hello Carlos, > >>> it occur 7-8 hour after i start nut. > >>> megatec binary dies. > >> Without more information (a stack trace or something), it's kind of > >> difficult to find the problem. It can be a megatec issue, or an issue > >> with the driver host. > >> PS: Please keep the list CC:ed. > > > > -- > > Best regards, > > Ercan mailto:ercan at eryaz.net-- Carlos Rodrigues
Asking for UPS status [Q1]... Q1 => OK [(214.5 214.5 220.1 030 49.9 2.22 41.5 00000000] Calculated battery charge: 100.0% Asking for UPS status [Q1]... Q1 => OK [(214.5 214.5 220.1 030 49.9 2.22 41.5 0000000000000000] Calculated battery charge: 100.0% *** stack smashing detected ***: megatec terminated ======= Backtrace: ========/lib/libc.so.6(__fortify_fail+0x48)[0x9b6ce8] /lib/libc.so.6(__fortify_fail+0x0)[0x9b6ca0] megatec[0x804a71a] megatec[0x804d250] [0x871abe8] ======= Memory map: =======00110000-00111000 r-xp 00110000 00:00 0 [vdso] 00111000-0011b000 r-xp 00000000 08:01 15467217 /lib/libnss_files-2.8.so 0011b000-0011c000 r--p 0000a000 08:01 15467217 /lib/libnss_files-2.8.so 0011c000-0011d000 rw-p 0000b000 08:01 15467217 /lib/libnss_files-2.8.so 008a0000-008bc000 r-xp 00000000 08:01 15826946 /lib/ld-2.8.so 008bc000-008bd000 r--p 0001c000 08:01 15826946 /lib/ld-2.8.so 008bd000-008be000 rw-p 0001d000 08:01 15826946 /lib/ld-2.8.so 008c0000-00a23000 r-xp 00000000 08:01 15826953 /lib/libc-2.8.so 00a23000-00a25000 r--p 00163000 08:01 15826953 /lib/libc-2.8.so 00a25000-00a26000 rw-p 00165000 08:01 15826953 /lib/libc-2.8.so 00a26000-00a29000 rw-p 00a26000 00:00 0 00d2b000-00d38000 r-xp 00000000 08:01 15826975 /lib/libgcc_s-4.3.0-20080428.so.1 00d38000-00d39000 rw-p 0000c000 08:01 15826975 /lib/libgcc_s-4.3.0-20080428.so.1 08048000-08054000 r-xp 00000000 08:01 17236226 /sbin/megatec 08054000-08055000 rw-p 0000c000 08:01 17236226 /sbin/megatec 08719000-0873a000 rw-p 08719000 00:00 0 [heap] b7fbc000-b7fbe000 rw-p b7fbc000 00:00 0 b7fd1000-b7fd2000 rw-p b7fd1000 00:00 0 bf8bc000-bf8d1000 rw-p bffeb000 00:00 0 [stack] Aborted [root at ginning ~]# [root at ginning ~]# Broadcast message from nut (Tue Jul 1 18:07:45 2008): Communications with UPS tuncmatik at 192.168.1.2 lost Tuesday, July 1, 2008, 4:58:39 PM, you wrote:> On Tue, Jul 1, 2008 at 2:47 PM, Ercan Istek <ercan at eryaz.net> wrote: >> Hello Carlos,>> it occur 7-8 hour after i start nut.>> megatec binary dies.> Without more information (a stack trace or something), it's kind of > difficult to find the problem. It can be a megatec issue, or an issue > with the driver host.> PS: Please keep the list CC:ed.-- Best regards, Ercan mailto:ercan at eryaz.net
On Wed, Jul 02, 2008 at 11:35:27AM +0300, Ercan Istek wrote:> Asking for UPS status [Q1]... > Q1 => OK [(214.5 214.5 220.1 030 49.9 2.22 41.5 00000000] > Calculated battery charge: 100.0% > Asking for UPS status [Q1]... > Q1 => OK [(214.5 214.5 220.1 030 49.9 2.22 41.5 0000000000000000] > Calculated battery charge: 100.0% > *** stack smashing detected ***: megatec terminated > ======= Backtrace: ========> /lib/libc.so.6(__fortify_fail+0x48)[0x9b6ce8] > /lib/libc.so.6(__fortify_fail+0x0)[0x9b6ca0] > megatec[0x804a71a] > megatec[0x804d250] > [0x871abe8]The best way to debug this would be to rebuild nut with "-O0 -g" and then run the driver under valgrind. Gabor -- --------------------------------------------------------- MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences ---------------------------------------------------------
>> Asking for UPS status [Q1]... >> Q1 => OK [(214.5 214.5 220.1 030 49.9 2.22 41.5 00000000] >> Calculated battery charge: 100.0% >> Asking for UPS status [Q1]... >> Q1 => OK [(214.5 214.5 220.1 030 49.9 2.22 41.5 0000000000000000] >> Calculated battery charge: 100.0% >> *** stack smashing detected ***: megatec terminated >> ======= Backtrace: ========>> /lib/libc.so.6(__fortify_fail+0x48)[0x9b6ce8] >> /lib/libc.so.6(__fortify_fail+0x0)[0x9b6ca0] >> megatec[0x804a71a] >> megatec[0x804d250] >> [0x871abe8] > The best way to debug this would be to rebuild nut with "-O0 -g" and > then run the driver under valgrind.That would be nice, but not really needed. The debugging information provided already shows where the problem lies. The flags in the Q1 command are overflowing the buffer that is reserved for it. This driver expects only 8 characters and not 16. Most likely, this is a bug in the UPS (since the Megatec protocol only defines 8 characters here). Arguably, the driver could be made more robust to deal with situations like this, by telling sscanf() to only copy as many characters as will fit in the buffer allocated for a certain parameter. Making assumptions about the size of data elements that are returned occasionally leads to problems like these. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57
On Tue, Jul 1, 2008 at 10:04 AM, Ercan Istek <ercan at eryaz.net> wrote:> > Jul 1 11:56:46 ginning upsd[10590]: Can't connect to UPS [tuncmatik] > (megatec-tuncmatik): Connection refused > > Jul 1 11:56:46 ginning upsd[10590]: Data for UPS [tuncmatik] is stale - > check driver > > Jul 1 11:56:46 ginning kernel: megatec[21553]: segfault at 100 ip 00d32216 > sp bffb05f0 error 4 in libgcc_s-4.3.0-20080428.so.1[d2b000+d000] > > What is the problem ?Can you try the latest version of the driver (from SVN)? This should be fixed. -- Carlos Rodrigues