You are not logged in.
Hello,
Since my glibc update to version 2.10.1-4 with pacman i noticed that several applications are crashing because of glibc segfaults,
for example my xfce terminal:
Terminal[7666]: segfault at bf398fe4 ip b6eb0bc2 sp bf398fe8 error 6 in libc-2.10.1.so[b6e55000+140000]Besides that, every application which is able to start crashes when i have to type something into a dialog box.
I rebuild glibc with the changes as mentioned in http://sourceware.org/ml/libc-help/2009 … 00049.html, but still no luck.
Somebody experiencing similar problems?
Every pointer to solve this annoying flaw would be highly appreciated ![]()
Offline
Hello again,
i looked further into this matter, examining mousepad with valgrind, which indicated an issue with fxstat64@@GLIBC, so i wrote this piece of code to reproduce the segfault:
/* glibc-2.10.1 Segfault-Test */
#include "stdio.h"
#include "stdlib.h"
#include "sys/stat.h"
#include "fcntl.h"
#include "unistd.h"
int main() {
struct stat* flst;
int fd; /* file descriptor */
fd=open("test.txt",O_RDONLY);
if(fstat(fd,flst) == 0) {
printf("%s","fstat 0\n");
} else {
printf("%s","fstat != 0\n");
}
close(fd);
return 0;
}compiled and executed with:
$ gcc test_fstat.c && ./a.out
Segmentation faultafter this i used valgrind, which gave me the following output:
==13024== Memcheck, a memory error detector
==13024== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==13024== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==13024== Command: ./a.out
==13024==
==13024== Use of uninitialised value of size 4
==13024== at 0x4107B8D: __xstat32_conv (in /lib/libc-2.10.1.so)
==13024== by 0x4100E87: _fxstat (in /lib/libc-2.10.1.so)
==13024== by 0x804854B: fstat (in /home/edward/source/segfault-glibc-2.10.1/a.out)
==13024== by 0x8048478: main (in /home/edward/source/segfault-glibc-2.10.1/a.out)
==13024==
==13024==
==13024== Process terminating with default action of signal 11 (SIGSEGV)
==13024== Bad permissions for mapped region at address 0x80484D3
==13024== at 0x4107B8D: __xstat32_conv (in /lib/libc-2.10.1.so)
==13024== by 0x4100E87: _fxstat (in /lib/libc-2.10.1.so)
==13024== by 0x804854B: fstat (in /home/edward/source/segfault-glibc-2.10.1/a.out)
==13024== by 0x8048478: main (in /home/edward/source/segfault-glibc-2.10.1/a.out)
==13024==
==13024== HEAP SUMMARY:
==13024== in use at exit: 0 bytes in 0 blocks
==13024== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==13024==
==13024== All heap blocks were freed -- no leaks are possible
==13024==
==13024== For counts of detected and suppressed errors, rerun with: -v
==13024== Use --track-origins=yes to see where uninitialised values come from
==13024== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 13 from 8)Well i am no programmer at all, but i guess all the segfaults i have with midori,mousepad,guake,terminal etc. are related to this glibc issue. Can someone help me please, or do I need to give more information?
Offline
Hi,
I have the same issue with a application I wrote, since last upgrade it crash with no reason ![]()
Offline
<snip>
Edit: of course I did not read the test case code. I get the segfault when adding the test.txt file to the run directory.
Edit again: this is i686 specific.
Offline
Hello fellow Archers,
I recompiled glibc with debug symbols to investigate further, and debugged the testprogramm to share the results with you:
edward ~/source/segfault-glibc-2.10.1 $ gdb ./a.out
GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/edward/source/segfault-glibc-2.10.1/a.out...done.
(gdb) r
Starting program: /home/edward/source/segfault-glibc-2.10.1/a.out
Program received signal SIGSEGV, Segmentation fault.
__xstat32_conv (vers=3, kbuf=0xbfffefb4, buf=0x80484eb) at ../sysdeps/unix/sysv/linux/xstatconv.c:194
194 buf->__pad1 = 0;
(gdb) bt
#0 __xstat32_conv (vers=3, kbuf=0xbfffefb4, buf=0x80484eb) at ../sysdeps/unix/sysv/linux/xstatconv.c:194
#1 0xb7f26a80 in *__GI___fxstat (vers=3, fd=-1073745996, buf=0x80484eb) at ../sysdeps/unix/sysv/linux/i386/fxstat.c:63
#2 0x0804856c in fstat ()
#3 0x08048499 in main () at test_fstat.c:16
(gdb) info r
eax 0x80484eb 134513899
ecx 0xbfffefb4 -1073745996
edx 0xbfffefb4 -1073745996
ebx 0xb7fbfff4 -1208221708
esp 0xbfffef8c 0xbfffef8c
ebp 0xbfffefa0 0xbfffefa0
esi 0xfe02 65026
edi 0x0 0
eip 0xb7f2d93d 0xb7f2d93d <__xstat32_conv+77>
eflags 0x10246 [ PF ZF IF RF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
(gdb) info sha
From To Syms Read Shared Object Library
0xb7fe17f0 0xb7ff808f Yes /lib/ld-linux.so.2
0xb7e7f810 0xb7f76b74 Yes /lib/libc.so.6
(gdb)Investigation of xstat32_conv shows that segfault occurs when trying to set __pad1 of struct kernel_stat to zero.
struct stat defined by kernel headers in /usr/include/asm/stat.h differs from the kernel_stat.h definition in glibc, does this matter?
Maybe the whole kernel_stat structure does not fit? (Datatypes, Naming...)
I am just guessing, because i have not enough knowledge to investigate this, but maybe someone more proficient can tell?
I recompiled with _HAVE_STAT___PAD1 etc. undefined, to avoid the writing to __pad1 (it is enclosed in #ifdef) but no luck, crash at another line:
edward ~/source/segfault-glibc-2.10.1 $ gdb ./a.out
GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/edward/source/segfault-glibc-2.10.1/a.out...done.
(gdb) s
The program is not being run.
(gdb) start
Temporary breakpoint 1 at 0x804846d: file test_fstat.c, line 14.
Starting program: /home/edward/source/segfault-glibc-2.10.1/a.out
Temporary breakpoint 1, main () at test_fstat.c:14
14 fd=open("test.txt",O_RDONLY);
(gdb) n
16 if(fstat(fd,flst) == 0) {
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
0xb7f2d93d in __xstat32_conv (vers=3, kbuf=0xbfffefb4, buf=0x80484eb) at ../sysdeps/unix/sysv/linux/xstatconv.c:192
192 buf->st_dev = kbuf->st_dev;
(gdb) bt
#0 0xb7f2d93d in __xstat32_conv (vers=3, kbuf=0xbfffefb4, buf=0x80484eb) at ../sysdeps/unix/sysv/linux/xstatconv.c:192
#1 0xb7f26a80 in *__GI___fxstat (vers=3, fd=134513899, buf=0x80484eb) at ../sysdeps/unix/sysv/linux/i386/fxstat.c:63
#2 0x0804856c in fstat ()
#3 0x08048499 in main () at test_fstat.c:16
(gdb) info r
eax 0xbfffefb4 -1073745996
ecx 0xbfffefb4 -1073745996
edx 0x80484eb 134513899
ebx 0xb7fbfff4 -1208221708
esp 0xbfffef8c 0xbfffef8c
ebp 0xbfffefa0 0xbfffefa0
esi 0xfe02 65026
edi 0x0 0
eip 0xb7f2d93d 0xb7f2d93d <__xstat32_conv+77>
eflags 0x10246 [ PF ZF IF RF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
(gdb) info sha
From To Syms Read Shared Object Library
0xb7fe17f0 0xb7ff808f Yes /lib/ld-linux.so.2
0xb7e7f810 0xb7f76b64 Yes /lib/libc.so.6
(gdb)I suspect that st_dev is not the same datatype, which leads to the crash when trying to convert the structure.
I am not sure what all this is about, maybe the error lies within the kernel? I am using the arch stock kernel, btw.
Thanks for looking into this, i really appreciate every help!
Edit: Despite the different architecture, maybe this issues are linked? http://bbs.archlinux.org/viewtopic.php?id=73292
Last edited by Oberstrolch (2009-10-26 19:04:46)
Offline
Updated to glibc-2.10.1-5, still the same issues. I thought i add some additional information about my system, and some thoughts i recently had. My Arch runs on a Laptop, Intel platform, stock packages, nothing from testing repo, a few applications from aur.
Archlinux used to work fine, until the segfaults occured.
I thought that maybe the code, which is segfaulting in glibc has not been altered for a while, but more likely the kernel has changed, which in combination with the glibc code segfaults. Is this likely? Maybe someone who has a bigger picture about kernel/glibc co-existence can answer this?
What shall I do? In which direction do i have to look? Or do i miss something fundamental?
I appreciate every thought or feedback and i am willing to try everything that might solve this problem!
--
Some additional information:
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
05:07.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
05:07.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller
05:07.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
05:07.3 SD Host controller: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller
05:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)Module Size Used by
usblp 13244 0
i915 231880 1
drm 156160 2 i915
i2c_algo_bit 5888 1 i915
ipv6 279636 20
ext2 68964 1
mbcache 7104 1 ext2
snd_seq_dummy 2720 0
snd_seq_oss 31232 0
snd_seq_midi_event 7036 1 snd_seq_oss
snd_seq 53808 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_seq_device 6792 3 snd_seq_dummy,snd_seq_oss,snd_seq
snd_pcm_oss 40320 0
snd_mixer_oss 17564 2 snd_pcm_oss
snd_hda_codec_si3054 5052 1
arc4 1756 2
ecb 2812 2
snd_hda_codec_realtek 210048 1
snd_hda_intel 27528 2
snd_hda_codec 72700 3 snd_hda_codec_si3054,snd_hda_codec_realtek,snd_hda_intel
iwl3945 89020 0
iwlcore 107132 1 iwl3945
snd_hwdep 7712 1 snd_hda_codec
snd_pcm 74464 4 snd_pcm_oss,snd_hda_codec_si3054,snd_hda_intel,snd_hda_codec
mac80211 155756 2 iwl3945,iwlcore
pcmcia 36168 0
snd_timer 21156 2 snd_seq,snd_pcm
sdhci_pci 7516 0
fan 4448 0
snd 58820 14 snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_hda_codec_si3054,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer
cfg80211 90428 3 iwl3945,iwlcore,mac80211
sdhci 17504 1 sdhci_pci
iTCO_wdt 11072 0
yenta_socket 25256 1
ohci1394 30220 0
soundcore 6944 2 snd
tifm_7xx1 5756 0
mmc_core 53080 1 sdhci
r8169 33984 0
cpufreq_userspace 3008 0
iTCO_vendor_support 3136 1 iTCO_wdt
rsrc_nonstatic 12316 1 yenta_socket
ieee1394 85668 1 ohci1394
snd_page_alloc 8900 2 snd_hda_intel,snd_pcm
tifm_core 7448 1 tifm_7xx1
i2c_i801 9616 0
cpufreq_powersave 1404 0
cpufreq_ondemand 7400 2
mii 4892 1 r8169
pcmcia_core 35184 3 pcmcia,yenta_socket,rsrc_nonstatic
led_class 4000 3 iwl3945,iwlcore,sdhci
intel_agp 28348 1
video 20116 1 i915
agpgart 32660 3 drm,intel_agp
i2c_core 21808 4 i915,drm,i2c_algo_bit,i2c_i801
rfkill 19728 1 cfg80211
psmouse 59764 0
pcspkr 2492 0
phc_intel 12584 0
output 2908 1 video
serio_raw 5792 0
evdev 10240 6
sg 27728 0
battery 10816 0
button 5612 0
ac 4224 0
thermal 13912 0
freq_table 3740 2 cpufreq_ondemand,phc_intel
processor 36076 3 phc_intel
rtc_cmos 11344 0
rtc_core 17976 1 rtc_cmos
rtc_lib 2524 1 rtc_core
reiserfs 242088 2
aes_i586 8124 8
aes_generic 27228 1 aes_i586
xts 3164 3
gf128mul 8604 1 xts
dm_crypt 13664 3
dm_mod 71076 7 dm_crypt
sr_mod 16644 0
sd_mod 28344 5
cdrom 36032 1 sr_mod
pata_acpi 4252 0
ata_generic 4704 0
uhci_hcd 23596 0
ehci_hcd 36652 0
ata_piix 23268 4
libata 169260 3 pata_acpi,ata_generic,ata_piix
scsi_mod 112436 4 sg,sr_mod,sd_mod,libata
usbcore 154032 4 usblp,uhci_hcd,ehci_hcdOffline
Hello again,
i looked further into this matter, examining mousepad with valgrind, which indicated an issue with fxstat64@@GLIBC, so i wrote this piece of code to reproduce the segfault:
/* glibc-2.10.1 Segfault-Test */ #include "stdio.h" #include "stdlib.h" #include "sys/stat.h" #include "fcntl.h" #include "unistd.h" int main() { struct stat* flst; int fd; /* file descriptor */ fd=open("test.txt",O_RDONLY); if(fstat(fd,flst) == 0) { printf("%s","fstat 0\n"); } else { printf("%s","fstat != 0\n"); } close(fd); return 0; }
This code is wrong. You need to allocate space for flst. Two ways :
1) static allocation : struct stat flst; then use &flst
2) dynamic : flst = malloc(sizeof(struct stat)) ; ... ; free(flst)
This is what caused your segfault.
If you are the only one having segfaults on many applications, this should indicate a somehow broken system ![]()
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
This code is wrong. You need to allocate space for flst. Two ways :
1) static allocation : struct stat flst; then use &flst
2) dynamic : flst = malloc(sizeof(struct stat)) ; ... ; free(flst)This is what caused your segfault.
If you are the only one having segfaults on many applications, this should indicate a somehow broken system
Thanks for your answer! I used method 1) and it worked out, but my other applications like terminal, guake, mousepad etc. are still segfaulting. Yeah i guess my system is broken, but i have no clue where it is broken ![]()
As silly as this question might sound, but how do i find out where it is broken? Because every application that is crashing reports a segfault in glibc, i suspect glibc is to be blamed (besides me, eventually
)
Offline
Thanks for your answer! I used method 1) and it worked out, but my other applications like terminal, guake, mousepad etc. are still segfaulting. Yeah i guess my system is broken, but i have no clue where it is broken
As silly as this question might sound, but how do i find out where it is broken? Because every application that is crashing reports a segfault in glibc, i suspect glibc is to be blamed (besides me, eventually)
So if you already did the obvious first steps :
- using common sense, thinking what you could have broken
- checking system logs
- checking pacman logs, shell history
- reinstalling glibc and all other dependencies of your segfaulting app (eg if its a gtk checkbox -> gtk)
- checking free disk space and free memory
and there is absolutely nothing wrong, then I would go on with the road you were taking (recompiling needed deps with debug symbols and using gdb to get a trace).
But you need to repeat it with a non-buggy program that is not supposed to segfault ![]()
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline