Re: PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
> reproduce the exact kernel configuration of my running 2.2.14 system > and a 2.2.17 kernel. (It would be extremely useful to have a pointer > to a tool which would duplicate the configs rather than going through > the manual process of configuring the kernel build). cp .config new_kernel_dir cd new_kernel_dir make menuconfig make dep; make clean; make bzImage Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
On Sat, 16 Sep 2000, David Ford wrote: > There was a round of discussion about /proc.../serial back in May. It > covered corruption and bad addresses. Although it didn't specifically say > "I'm fixing the segmentation fault that some people are going to report", > they did indeed discuss the bad data, smp locking, and etc precisely on > serial.c. > > If a specific problem such as a bad address went away by upgrading, there's a > very strong chance that the bug was fixed. Such problems aren't likely to > migrate around in the kernel and be hidden, they tend to stay localized. > Instead of searching for a given author's comments, diff the two files and > see if the initializing code changed. A lot of fixes go in without specific > credits. That's also my thought.. I'll diff the files tomorrow, and see what comes out. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
> Igmar, > > Thanks for attempting to validate that the problem is fixed in a > later release. However, I still stand by my submission. The problem was that the kernel was overwriting a userspace buffer, used to copy the data to. I can have a look at the code to see if it is really fixed. It seems really fixed, even dd likes the new sitation.. It always segfaulted with the old kernel. > If the readers will note, the problem is in 2.2.14 and > AND in 2.3.5 as referenced by another auther. It looks like the Both kernels are VERY OLD. 2.3.5 is ancient, 2.2.14 is also. Upgrading should be done anyway due to security bugs present in < 2.2.16 > info structure in drivers/char/serial.c:line_info is not sufficiently > initialized in all cases that might be processed by serial_in() > for instance, the CONFIG_HUB6 case. If line_info populates an > info struct and CONFIG_HUB6 is defined and info->hub6 is > dereferenced, there may well be garbage in info->hub6. > > I've searched the source trees and I don't see any of the fixes > between 2.2.14 and 2.2.17 referenced by the previous author at > the end of my original post. > > That said, the incompletely initialized "info" structure problem > exists. The fact that you and many others may not encountered the > problem is pure happenstance either because CONFIG_HUB6 was not > configured or you were lucky enough not to have garbage in any > of the data structures. > > So, if I upgraded to 2.2.17 and the problem went away, that doesn't > mean the problem doesn't exist, it just means that the problem may > simply be being masked or has not yet been encountered. I'll have a look at the code these days.. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
Igmar, Thanks for attempting to validate that the problem is fixed in a later release. However, I still stand by my submission. The problem was that the kernel was overwriting a userspace buffer, used to copy the data to. I can have a look at the code to see if it is really fixed. It seems really fixed, even dd likes the new sitation.. It always segfaulted with the old kernel. If the readers will note, the problem is in 2.2.14 and AND in 2.3.5 as referenced by another auther. It looks like the Both kernels are VERY OLD. 2.3.5 is ancient, 2.2.14 is also. Upgrading should be done anyway due to security bugs present in 2.2.16 info structure in drivers/char/serial.c:line_info is not sufficiently initialized in all cases that might be processed by serial_in() for instance, the CONFIG_HUB6 case. If line_info populates an info struct and CONFIG_HUB6 is defined and info-hub6 is dereferenced, there may well be garbage in info-hub6. I've searched the source trees and I don't see any of the fixes between 2.2.14 and 2.2.17 referenced by the previous author at the end of my original post. That said, the incompletely initialized "info" structure problem exists. The fact that you and many others may not encountered the problem is pure happenstance either because CONFIG_HUB6 was not configured or you were lucky enough not to have garbage in any of the data structures. So, if I upgraded to 2.2.17 and the problem went away, that doesn't mean the problem doesn't exist, it just means that the problem may simply be being masked or has not yet been encountered. I'll have a look at the code these days.. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
On Sat, 16 Sep 2000, David Ford wrote: There was a round of discussion about /proc.../serial back in May. It covered corruption and bad addresses. Although it didn't specifically say "I'm fixing the segmentation fault that some people are going to report", they did indeed discuss the bad data, smp locking, and etc precisely on serial.c. If a specific problem such as a bad address went away by upgrading, there's a very strong chance that the bug was fixed. Such problems aren't likely to migrate around in the kernel and be hidden, they tend to stay localized. Instead of searching for a given author's comments, diff the two files and see if the initializing code changed. A lot of fixes go in without specific credits. That's also my thought.. I'll diff the files tomorrow, and see what comes out. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
There was a round of discussion about /proc.../serial back in May. It covered corruption and bad addresses. Although it didn't specifically say "I'm fixing the segmentation fault that some people are going to report", they did indeed discuss the bad data, smp locking, and etc precisely on serial.c. If a specific problem such as a bad address went away by upgrading, there's a very strong chance that the bug was fixed. Such problems aren't likely to migrate around in the kernel and be hidden, they tend to stay localized. Instead of searching for a given author's comments, diff the two files and see if the initializing code changed. A lot of fixes go in without specific credits. -d David Ciemiewicz wrote: > Igmar, > > Thanks for attempting to validate that the problem is fixed in a > later release. However, I still stand by my submission. > > If the readers will note, the problem is in 2.2.14 and > AND in 2.3.5 as referenced by another auther. It looks like the > info structure in drivers/char/serial.c:line_info is not sufficiently > initialized in all cases that might be processed by serial_in() > for instance, the CONFIG_HUB6 case. If line_info populates an > info struct and CONFIG_HUB6 is defined and info->hub6 is > dereferenced, there may well be garbage in info->hub6. > > I've searched the source trees and I don't see any of the fixes > between 2.2.14 and 2.2.17 referenced by the previous author at > the end of my original post. > > That said, the incompletely initialized "info" structure problem > exists. The fact that you and many others may not encountered the > problem is pure happenstance either because CONFIG_HUB6 was not > configured or you were lucky enough not to have garbage in any > of the data structures. > > So, if I upgraded to 2.2.17 and the problem went away, that doesn't > mean the problem doesn't exist, it just means that the problem may > simply be being masked or has not yet been encountered. > > --- Ciemo > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;28256 fn:David Ford end:vcard
PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
Igmar, Thanks for attempting to validate that the problem is fixed in a later release. However, I still stand by my submission. If the readers will note, the problem is in 2.2.14 and AND in 2.3.5 as referenced by another auther. It looks like the info structure in drivers/char/serial.c:line_info is not sufficiently initialized in all cases that might be processed by serial_in() for instance, the CONFIG_HUB6 case. If line_info populates an info struct and CONFIG_HUB6 is defined and info->hub6 is dereferenced, there may well be garbage in info->hub6. I've searched the source trees and I don't see any of the fixes between 2.2.14 and 2.2.17 referenced by the previous author at the end of my original post. That said, the incompletely initialized "info" structure problem exists. The fact that you and many others may not encountered the problem is pure happenstance either because CONFIG_HUB6 was not configured or you were lucky enough not to have garbage in any of the data structures. So, if I upgraded to 2.2.17 and the problem went away, that doesn't mean the problem doesn't exist, it just means that the problem may simply be being masked or has not yet been encountered. --- Ciemo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
On Fri, 15 Sep 2000, David Ciemiewicz wrote: > [4.] Linux version 2.2.14-5.0 ([EMAIL PROTECTED]) (gcc version Don't report bugs with this old version. [root@base igmar]# uname -a Linux base.jdimedia.nl 2.2.17acl #2 Mon Sep 11 02:23:03 CEST 2000 i586 unknown [root@base igmar]# cat /proc/tty/driver/serial serinfo:1.0 driver:4.27 0: uart:16550A port:3F8 irq:4 baud:1200 tx:3328 rx:354427 fe:245 brk:914 RTS|DTR1: uart:16550A port:2F8 irq:3 baud:9600 tx:103818 rx:4576 CTS|DSR 2: uart:unknown port:3E8 irq:4 3: uart:unknown port:2E8 irq:3 Works fine here. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
On Fri, 15 Sep 2000, David Ciemiewicz wrote: [4.] Linux version 2.2.14-5.0 ([EMAIL PROTECTED]) (gcc version Don't report bugs with this old version. [root@base igmar]# uname -a Linux base.jdimedia.nl 2.2.17acl #2 Mon Sep 11 02:23:03 CEST 2000 i586 unknown [root@base igmar]# cat /proc/tty/driver/serial serinfo:1.0 driver:4.27 0: uart:16550A port:3F8 irq:4 baud:1200 tx:3328 rx:354427 fe:245 brk:914 RTS|DTR1: uart:16550A port:2F8 irq:3 baud:9600 tx:103818 rx:4576 CTS|DSR 2: uart:unknown port:3E8 irq:4 3: uart:unknown port:2E8 irq:3 Works fine here. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
There was a round of discussion about /proc.../serial back in May. It covered corruption and bad addresses. Although it didn't specifically say "I'm fixing the segmentation fault that some people are going to report", they did indeed discuss the bad data, smp locking, and etc precisely on serial.c. If a specific problem such as a bad address went away by upgrading, there's a very strong chance that the bug was fixed. Such problems aren't likely to migrate around in the kernel and be hidden, they tend to stay localized. Instead of searching for a given author's comments, diff the two files and see if the initializing code changed. A lot of fixes go in without specific credits. -d David Ciemiewicz wrote: Igmar, Thanks for attempting to validate that the problem is fixed in a later release. However, I still stand by my submission. If the readers will note, the problem is in 2.2.14 and AND in 2.3.5 as referenced by another auther. It looks like the info structure in drivers/char/serial.c:line_info is not sufficiently initialized in all cases that might be processed by serial_in() for instance, the CONFIG_HUB6 case. If line_info populates an info struct and CONFIG_HUB6 is defined and info-hub6 is dereferenced, there may well be garbage in info-hub6. I've searched the source trees and I don't see any of the fixes between 2.2.14 and 2.2.17 referenced by the previous author at the end of my original post. That said, the incompletely initialized "info" structure problem exists. The fact that you and many others may not encountered the problem is pure happenstance either because CONFIG_HUB6 was not configured or you were lucky enough not to have garbage in any of the data structures. So, if I upgraded to 2.2.17 and the problem went away, that doesn't mean the problem doesn't exist, it just means that the problem may simply be being masked or has not yet been encountered. --- Ciemo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE org:img src="http://www.kalifornia.com/images/paradise.jpg" adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;28256 fn:David Ford end:vcard
PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
[1.] Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
[2.] Programs which read from /proc/tty/driver/serial (using stdio?) will
terminate prematurely with a segmentation fault [SIGSEGV] and do not
produce a corefile.
This was discovered running the sysstat 3.4.2 sadc program which collects
data for sar system activity reporting.
Example:
$ cat /proc/tty/driver/serial
serinfo:1.0 driver:4.27
0: uart:16550A port:3F8 irq:4 baud:9600 tx:11 rx:0
1: uart:16550A port:2F8 irq:3 baud:9600 tx:11 rx:0
2: uart:unknown port:3E8 irq:4
3: uart:unknown port:2E8 irq:3
...
28: uart:unknown port:160 irq:12
29: uart:unknown port:1Segmentation fault
strace output shows that the SIGSEGV occurs in the read system call
open("/proc/tty/driver/serial", O_RDONLY|O_LARGEFILE) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(3, "serinfo:1.0 driver:4.27\n0: uart:"..., 512) = 512
write(1, "serinfo:1.0 driver:4.27\n0: uart:"..., 512serinfo:1.0 driver:4.27
0: uart:16550A port:3F8 irq:4 baud:9600 tx:11 rx:0
...
read(3, "14: uart:unknown port:0 irq:0\n15"..., 512) = 512
write(1, "14: uart:unknown port:0 irq:0\n15"..., 51214: uart:unknown port:0
irq:0
15: uart:unknown port:0 irq:0
...
read(3,
+++ killed by SIGSEGV +++
[3.] kernel old_mmap /proc/tty/driver/serial
[4.] Linux version 2.2.14-5.0 ([EMAIL PROTECTED]) (gcc version
egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Tue Mar 7 21:07:39 EST
2000
[5.] No applicable Oops
[6.]
#! /bin/sh
cat /proc/tty/driver/serial
[7.] Uniprocessor HP Vectra VL
[7.1.] sh ver_linux
-- Versions installed: (if some fields are empty or looks
-- unusual then possibly you have very old versions)
Linux ciemo-linux.sfo.logictier.com 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST
2000 i686 unknown
Kernel modules found
Gnu C egcs-2.91.66
Binutils 2.9.5.0.22
Linux C Library..
ldd: missing file arguments
Try `ldd --help' for more information.
ls: /usr/lib/libg++.so: No such file or directory
Procps 2.0.6
Mount 2.10f
Net-tools (1999-04-20)
Kbd[option...]
Sh-utils 2.0
Sh-utils Parker.
Sh-utils
Sh-utils Inc.
Sh-utils NO
Sh-utils PURPOSE.
[7.2.]cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 7
model name : Pentium III (Katmai)
stepping: 3
cpu MHz : 501.142695
cache size : 512 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
pat pse36 mmx fxsr xmm
bogomips: 499.71
[7.3.] cat /proc/modules
autofs 9092 1 (autoclean)
lockd 30344 1 (autoclean)
sunrpc 52132 1 (autoclean) [lockd]
3c59x 18980 1 (autoclean)
[7.4.] cat /proc/scsi/scsi
Attached devices: none
[7.5.] No other useful info from /proc
[X.]
See "/proc/tty/driver/serial kernel oops and other problems -- FIX" which
may
have applicability as a diagnosis of the problem and a proposed fix. The
bug
exists in 2.2.14 kernels, not just in 2.3.5 kernels as indicated by author.
http://uwsg.ucs.indiana.edu/hypermail/linux/kernel/9910.3/0091.html
See "sysstat 3.2.4" from Sebastian Godard
http://www.icewalk.com/softlib/app/app_00904.html
<>
David Ciemiewicz (E-mail).vcf
PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
[1.] Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial
[2.] Programs which read from /proc/tty/driver/serial (using stdio?) will
terminate prematurely with a segmentation fault [SIGSEGV] and do not
produce a corefile.
This was discovered running the sysstat 3.4.2 sadc program which collects
data for sar system activity reporting.
Example:
$ cat /proc/tty/driver/serial
serinfo:1.0 driver:4.27
0: uart:16550A port:3F8 irq:4 baud:9600 tx:11 rx:0
1: uart:16550A port:2F8 irq:3 baud:9600 tx:11 rx:0
2: uart:unknown port:3E8 irq:4
3: uart:unknown port:2E8 irq:3
...
28: uart:unknown port:160 irq:12
29: uart:unknown port:1Segmentation fault
strace output shows that the SIGSEGV occurs in the read system call
open("/proc/tty/driver/serial", O_RDONLY|O_LARGEFILE) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(3, "serinfo:1.0 driver:4.27\n0: uart:"..., 512) = 512
write(1, "serinfo:1.0 driver:4.27\n0: uart:"..., 512serinfo:1.0 driver:4.27
0: uart:16550A port:3F8 irq:4 baud:9600 tx:11 rx:0
...
read(3, "14: uart:unknown port:0 irq:0\n15"..., 512) = 512
write(1, "14: uart:unknown port:0 irq:0\n15"..., 51214: uart:unknown port:0
irq:0
15: uart:unknown port:0 irq:0
...
read(3, unfinished ...
+++ killed by SIGSEGV +++
[3.] kernel old_mmap /proc/tty/driver/serial
[4.] Linux version 2.2.14-5.0 ([EMAIL PROTECTED]) (gcc version
egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Tue Mar 7 21:07:39 EST
2000
[5.] No applicable Oops
[6.]
#! /bin/sh
cat /proc/tty/driver/serial
[7.] Uniprocessor HP Vectra VL
[7.1.] sh ver_linux
-- Versions installed: (if some fields are empty or looks
-- unusual then possibly you have very old versions)
Linux ciemo-linux.sfo.logictier.com 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST
2000 i686 unknown
Kernel modules found
Gnu C egcs-2.91.66
Binutils 2.9.5.0.22
Linux C Library..
ldd: missing file arguments
Try `ldd --help' for more information.
ls: /usr/lib/libg++.so: No such file or directory
Procps 2.0.6
Mount 2.10f
Net-tools (1999-04-20)
Kbd[option...]
Sh-utils 2.0
Sh-utils Parker.
Sh-utils
Sh-utils Inc.
Sh-utils NO
Sh-utils PURPOSE.
[7.2.]cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 7
model name : Pentium III (Katmai)
stepping: 3
cpu MHz : 501.142695
cache size : 512 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
pat pse36 mmx fxsr xmm
bogomips: 499.71
[7.3.] cat /proc/modules
autofs 9092 1 (autoclean)
lockd 30344 1 (autoclean)
sunrpc 52132 1 (autoclean) [lockd]
3c59x 18980 1 (autoclean)
[7.4.] cat /proc/scsi/scsi
Attached devices: none
[7.5.] No other useful info from /proc
[X.]
See "/proc/tty/driver/serial kernel oops and other problems -- FIX" which
may
have applicability as a diagnosis of the problem and a proposed fix. The
bug
exists in 2.2.14 kernels, not just in 2.3.5 kernels as indicated by author.
http://uwsg.ucs.indiana.edu/hypermail/linux/kernel/9910.3/0091.html
See "sysstat 3.2.4" from Sebastian Godard
http://www.icewalk.com/softlib/app/app_00904.html
David Ciemiewicz (E-mail).vcf
David Ciemiewicz (E-mail).vcf
