Bug 128670
| Summary: | Fail to run 'updatedb' | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Yao Zhang <yaoz> | ||||
| Component: | kernel | Assignee: | Dave Jones <davej> | ||||
| Status: | CLOSED NEXTRELEASE | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 2 | CC: | byte, hardawayd, pfrields | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2005-04-16 05:52:20 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Created attachment 102238 [details]
/var/log/message when updatedb segfault.
Fedora Core 3 test1, with slocate-2.7-11, this works for me out of the box - updatedb does not segfault Could you maybe provide more details about your hardware? From the attachment I enclosed, it looks like something to do with vfat. I have two vfat partitions on one SCSI drive: /dev/sda2 /mnt/nt.d vfat exec,dev,suid,rw 1 0 /dev/sda3 /mnt/nt.e vfat exec,dev,suid,rw 1 0 There is no problem with RH8.0, FC1 running on the same machine with the same configuration. I am having problems with updatedb also. I had filed a bug report prior and thought it was fixed but it was not--my mistake--they closed the bug report so I am continuing it here. The problem is that updatedb never finishes or finishes saying "segmentation fault". I think i know where the problem lies. I have two disks on my laptop--a windows disk and my linux disk. I have been having problems browsing into folders folders from the desktop on the windows disk and have a bug report filed. updatedb when tring to work thru the windows disk hangs up. I don't know if it is related or not to the browsing problem. From a terminal window i can navigate and copy files from the windows disk to my linux disk but can not do that using the desktop to click into folders on the windows disk. Hope this helps. I have the latest files for test3. I am having problems with updatedb also. I had filed a bug report prior and thought it was fixed but it was not--my mistake--they closed the bug report so I am continuing it here. The problem is that updatedb never finishes or finishes saying "segmentation fault". I think i know where the problem lies. I have two disks on my laptop--a windows disk and my linux disk. I have been having problems browsing into folders folders from the desktop on the windows disk and have a bug report filed. updatedb when tring to work thru the windows disk hangs up. I don't know if it is related or not to the browsing problem. From a terminal window i can navigate and copy files from the windows disk to my linux disk but can not do that using the desktop to click into folders on the windows disk. Hope this helps. I have the latest files for test3. is this still a problem with the latest updates ? It is still a problem with the latest updates. Just test it again with kernel-2.6.9-1.1018_FC4 and slocate-2.7-13. The file system the kernel has trouble with is vfat and some of its directory and file names are in encoding GB2312. It is mounted at /mnt/nt.e like /dev/sda3 /mnt/nt.e vfat exec,dev,suid,rw,shortname=mixed 1 0 When I run updatedb -U /mnt/nt.e it fails with /var/log/message: Dec 8 11:40:03 water kernel: Unable to handle kernel paging request at virtual address 676665ea Dec 8 11:40:03 water kernel: printing eip: Dec 8 11:40:03 water kernel: c01bee34 Dec 8 11:40:03 water kernel: *pde = 00000000 Dec 8 11:40:03 water kernel: Oops: 0000 [#1] Dec 8 11:40:03 water kernel: Modules linked in: parport_pc lp parport autofs4 nfs lockd sunrpc vfat fat dm_mod md5 ipv6 uhci_hcd emu10k1_gp gameport snd_emu10k1 snd_rawmidi snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_seq_device snd_ac97_codec snd_page_alloc snd_util_mem snd_hwdep snd soundcore e1000 floppy ext3 jbd aic7xxx sd_mod scsi_mod Dec 8 11:40:03 water kernel: CPU: 0 Dec 8 11:40:03 water kernel: EIP: 0060:[<c01bee34>] Not tainted VLI Dec 8 11:40:03 water kernel: EFLAGS: 00010202 (2.6.9-1.1018_FC4) Dec 8 11:40:03 water kernel: EIP is at uni2char+0x28/0x41 Dec 8 11:40:03 water kernel: eax: 00000086 ebx: cf48ad86 ecx: 67666564 edx: 00000099 Dec 8 11:40:03 water kernel: esi: cf48addc edi: cec6600a ebp: c03686e0 esp: cf48ad20 Dec 8 11:40:03 water kernel: ds: 007b es: 007b ss: 0068 Dec 8 11:40:04 water kernel: Process updatedb (pid: 2895, threadinfo=cf48a000 task=cfbe4e10) Dec 8 11:40:04 water kernel: Stack: cf48addc 00009986 d0a44dc1 cf48add8 00000000 cf48af00 c01bedf1 cf48af52 Dec 8 11:40:04 water kernel: 000019f8 d0a461f9 c03686e0 d2000040 00000000 00000000 00000006 00000006 Dec 8 11:40:04 water kernel: 0000000a 00000003 00000006 00000104 00000000 00000000 00000001 00000000 Dec 8 11:40:04 water kernel: Call Trace: Dec 8 11:40:04 water kernel: [<d0a44dc1>] uni16_to_x8+0x2d/0x83 [fat] Dec 8 11:40:04 water kernel: [<c01bedf1>] char2uni+0x0/0x1b Dec 8 11:40:04 water kernel: [<d0a461f9>] fat_readdirx+0xbfc/0xd69 [fat] Dec 8 11:40:04 water kernel: [<d0a48df9>] fat_fill_inode+0x227/0x246 [fat] Dec 8 11:40:04 water kernel: [<c01849ad>] d_splice_alias+0x20e/0x214 Dec 8 11:40:04 water kernel: [<d08bb44a>] vfat_lookup+0x33f/0x35e [vfat] Dec 8 11:40:04 water kernel: [<c0177f6f>] real_lookup+0x73/0xde Dec 8 11:40:04 water kernel: [<d08ba1f3>] vfat_cmpi+0x2e/0x83 [vfat] Dec 8 11:40:04 water kernel: [<d08ba1c5>] vfat_cmpi+0x0/0x83 [vfat] Dec 8 11:40:04 water kernel: [<c0184b05>] __d_lookup+0x121/0x21b Dec 8 11:40:04 water kernel: [<c01782b3>] do_lookup+0x1f/0x8f Dec 8 11:40:04 water kernel: [<c018241b>] dput+0x33/0x4f3 Dec 8 11:40:04 water kernel: [<c0179274>] link_path_walk+0xf51/0x1009 Dec 8 11:40:04 water kernel: [<c012aa2c>] update_wall_time+0x8/0x30 Dec 8 11:40:04 water kernel: [<c0173c01>] cp_new_stat64+0x124/0x139 Dec 8 11:40:04 water kernel: [<c017d5fa>] filldir64+0x0/0x11a Dec 8 11:40:04 water kernel: [<d0a4637d>] fat_readdir+0x17/0x1c [fat] Dec 8 11:40:04 water kernel: [<c017d5fa>] filldir64+0x0/0x11a Dec 8 11:40:04 water kernel: [<c017d332>] vfs_readdir+0x8a/0xb7 Dec 8 11:40:04 water kernel: [<c017d779>] sys_getdents64+0x65/0x9f Dec 8 11:40:04 water kernel: [<c031344b>] syscall_call+0x7/0xb Dec 8 11:40:04 water kernel: Code: c3 90 90 56 0f b7 c0 89 d6 53 89 c2 c1 ea 08 85 c9 88 c3 b8 dc ff ff ff 7e 27 0f b6 c2 8b 0c 85 e0 83 36 c0 85 c9 74 0b 0f b6 c3 <0f> b6 04 01 84 c0 75 07 b8 ea ff ff ff eb 07 88 06 b8 01 00 00 Not only updatedb failed on the fs, even ls will segfault too, with the following /var/log/message. It is definitely something with the new 2.6 kernel. The old 2.4 kernel (like in FC1) is fine. Dec 8 12:19:58 water kernel: Unable to handle kernel paging request at virtual address 676665ea Dec 8 12:19:58 water kernel: printing eip: Dec 8 12:19:58 water kernel: c01bee34 Dec 8 12:19:58 water kernel: *pde = 00000000 Dec 8 12:19:58 water kernel: Oops: 0000 [#1] Dec 8 12:19:58 water kernel: Modules linked in: parport_pc lp parport autofs4 nfs lockd sunrpc nls_cp936 vfat fat dm_mod md5 ipv6 uhci_hcd emu10k1_gp gameport snd_emu10k1 snd_rawmidi snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_seq_device snd_ac97_codec snd_page_alloc snd_util_mem snd_hwdep snd soundcore e1000 floppy ext3 jbd aic7xxx sd_mod scsi_mod Dec 8 12:19:58 water kernel: CPU: 0 Dec 8 12:19:58 water kernel: EIP: 0060:[<c01bee34>] Not tainted VLI Dec 8 12:19:58 water kernel: EFLAGS: 00210202 (2.6.9-1.1018_FC4) Dec 8 12:19:58 water kernel: EIP is at uni2char+0x28/0x41 Dec 8 12:19:58 water kernel: eax: 00000086 ebx: c2141d86 ecx: 67666564 edx: 00000099 Dec 8 12:19:58 water kernel: esi: c2141ddc edi: c20a600a ebp: c03686e0 esp: c2141d20 Dec 8 12:19:58 water kernel: ds: 007b es: 007b ss: 0068 Dec 8 12:19:58 water kernel: Process ls (pid: 2812, threadinfo=c2141000 task=c219a690) Dec 8 12:19:58 water kernel: Stack: c2141ddc 00009986 d0a44dc1 c2141dd8 00000000 c2141f00 d0ab707c c2141f52 Dec 8 12:19:58 water kernel: 00000674 d0a461f9 c03686e0 d207806a 00000000 00000000 00000006 00000006 Dec 8 12:19:58 water kernel: 0000000a 00000003 00000006 00000104 00000000 00000000 00000001 00000000 Dec 8 12:19:58 water kernel: Call Trace: Dec 8 12:19:58 water kernel: [<d0a44dc1>] uni16_to_x8+0x2d/0x83 [fat] Dec 8 12:19:58 water kernel: [<d0ab707c>] char2uni+0x0/0x7c [nls_cp936] Dec 8 12:19:58 water kernel: [<d0a461f9>] fat_readdirx+0xbfc/0xd69 [fat] Dec 8 12:19:58 water kernel: [<d08d3d3a>] __ext3_journal_stop+0x19/0x34 [ext3] Dec 8 12:19:58 water kernel: [<c0190b4e>] __mark_inode_dirty+0x2a/0x254 Dec 8 12:19:58 water kernel: [<c0188bd9>] update_atime+0x6a/0x90 Dec 8 12:19:58 water kernel: [<c01494df>] buffered_rmqueue+0x1dd/0x200 Dec 8 12:19:58 water kernel: [<c01495b6>] __alloc_pages+0xb4/0x298 Dec 8 12:19:58 water kernel: [<c0145168>] find_get_page+0x83/0xfe Dec 8 12:19:58 water kernel: [<c01461fe>] filemap_nopage+0x148/0x29e Dec 8 12:19:58 water kernel: [<c01571b6>] do_no_page+0x3b5/0x434 Dec 8 12:19:58 water kernel: [<c015742b>] handle_mm_fault+0xe5/0x233 Dec 8 12:19:58 water kernel: [<c011a688>] do_page_fault+0x1ac/0x4dc Dec 8 12:19:58 water kernel: [<c017d5fa>] filldir64+0x0/0x11a Dec 8 12:19:58 water kernel: [<d0a4637d>] fat_readdir+0x17/0x1c [fat] Dec 8 12:19:58 water kernel: [<c017d5fa>] filldir64+0x0/0x11a Dec 8 12:19:58 water kernel: [<c017d332>] vfs_readdir+0x8a/0xb7 Dec 8 12:19:58 water kernel: [<c017d779>] sys_getdents64+0x65/0x9f Dec 8 12:19:58 water kernel: [<c031344b>] syscall_call+0x7/0xb Dec 8 12:19:58 water kernel: Code: c3 90 90 56 0f b7 c0 89 d6 53 89 c2 c1 ea 08 85 c9 88 c3 b8 dc ff ff ff 7e 27 0f b6 c2 8b 0c 85 e0 83 36 c0 85 c9 74 0b 0f b6 c3 <0f> b6 04 01 84 c0 75 07 b8 ea ff ff ff eb 07 88 06 b8 01 00 00 Did more testing and found a solution. The fs with the problem is FAT16. Some of its directory and file names are in Chinese. They are created by a Chinese book reader under NT 4. So the encoding is not GB2312, the encoding is UCS2. Those directory and file names have lots of '\0's in them which confuses kernel 2.6. I don't know why kernel 2.4 has no problem. The solution is mounting it with 'utf8' vfat specific option, as in /etc/fstab: /dev/sda3 /mnt/nt.e vfat exec,dev,suid,rw,shortname=mixed,utf8 1 0 Then updatedb and ls are working again. Of cause, if under kernel 2.6, at least it does not cause segfault even no 'utf8' option is specified, that would be much better. Basically, after the segfault, that partition is no longer accessible: not even umount. Have to reboot to regain access to the partition. Fedora Core 2 has now reached end of life, and no further updates will be provided by Red Hat. The Fedora legacy project will be producing further kernel updates for security problems only. If this bug has not been fixed in the latest Fedora Core 2 update kernel, please try to reproduce it under Fedora Core 3, and reopen if necessary, changing the product version accordingly. Thank you. |
Description of problem: Run 'updatedb' by cron or command line, get segmentation fault, and datebase is not created. Version-Release number of selected component (if applicable): sloate-2.7.11 How reproducible: Always. Steps to Reproduce: 1. su -c updatedb 2. After a while, get Segmentation fault 3. locate ls results warning: locate: could not open database: /var/lib/slocate/slocate.db: No such file or directory warning: You need to run the 'updatedb' command (as root) to create the database. Actual results: Expected results: Additional info: