Description of problem: while querying kernel sources, the stack gets corrupted Version-Release number of selected component (if applicable): [root@gondor boot]# rpm -qv cscope cscope-15.5-15.4.fc7 [root@gondor boot]# How reproducible: Always. Steps to Reproduce: 1. Generate the cscope database for the kernel sources using make cscope 2. Run cscope -d 3. Search for functions calling force_quiescent state. Actual results: Searching*** stack smashing detected ***: /usr/bin/cscope terminated Program received signal SIGSEGV, Segmentation fault. uw_update_context (context=0xbfa1baf4, fs=<value optimized out>) at ../../gcc/unwind-dw2.c:173 173 return * (_Unwind_Ptr *) ptr; (gdb) bt #0 uw_update_context (context=0xbfa1baf4, fs=<value optimized out>) at ../../gcc/unwind-dw2.c:173 #1 0x0020976e in _Unwind_Backtrace (trace=0xa84dd0 <backtrace_helper>, trace_argument=0xbfa1bb90) at ../../gcc/unwind.inc:307 #2 0x00a84fa8 in __backtrace (array=0xbfa1c0a0, size=64) at ../sysdeps/i386/backtrace.c:122 #3 0x009ffa01 in __libc_message (do_abort=2, fmt=0xac7833 "*** %s ***: %s terminated\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:150 #4 0x00a87b58 in __fortify_fail (msg=0xac781b "stack smashing detected") at fortify_fail.c:32 #5 0x00a87b10 in __stack_chk_fail () at stack_chk_fail.c:29 #6 0x08054804 in search () at display.c:536 #7 0x08050200 in command (commandc=Cannot access memory at address 0x2c70647a ) at command.c:522 Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) (inside gdb) Expected results: Should successfully return the functions calling the force_quiescent_state function. Additional info:
Created attachment 310022 [details] patch to truncate paths at max length yuk. Do you have a refernce to the kernel tree you were using? I just tried with the latest linus tree and it seems to work (not that that means anything), but I'd like to be able to recreate this. First guess is that the file name is getting overrun. The attached patch is untested, but I think it may help. Please give it a spin and let me know. Thanks!
481c5346d0981940ee63037eb53e4e37b0735c10 is the top level commit on the tree I have at the moment. OK, sorry for the dumb question, how do I apply this patch? Should I download the src rpm and set it up there? Thanks
Never mind, I built an rpm with that patch, and I still hit the same issue. Searching*** stack smashing detected ***: /usr/bin/cscope terminated Program received signal SIGSEGV, Segmentation fault. uw_update_context (context=0xbf8ed1d4, fs=<value optimized out>) at ../../gcc/unwind-dw2.c:173 173 return * (_Unwind_Ptr *) ptr; (gdb) bt #0 uw_update_context (context=0xbf8ed1d4, fs=<value optimized out>) at ../../gcc/unwind-dw2.c:173 #1 0x0020976e in _Unwind_Backtrace (trace=0xa84dd0 <backtrace_helper>, trace_argument=0xbf8ed270) at ../../gcc/unwind.inc:307 #2 0x00a84fa8 in __backtrace (array=0xbf8ed780, size=64) at ../sysdeps/i386/backtrace.c:122 #3 0x009ffa01 in __libc_message (do_abort=2, fmt=0xac7833 "*** %s ***: %s terminated\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:150 #4 0x00a87b58 in __fortify_fail (msg=0xac781b "stack smashing detected") at fortify_fail.c:32 #5 0x00a87b10 in __stack_chk_fail () at stack_chk_fail.c:29 #6 0x08054fd4 in search () at display.c:536 #7 0x08050200 in command (commandc=Cannot access memory at address 0x2c70647a ) at command.c:76 Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb)
ok, well, theres only three likely copies in the search function that can cause this: The file, function and linenum arrays. I'm still unable to reproduce, but I'll keep trying: In the interim, lets determine which of these arrays is getting overrun. If you find the search function, you'll see each of the arrays defined at the top of the function. I'd suggest modifying them one at a time, to be something on the order of 8k in size. That should prevent any overruns. When the smash stops happening, we've found the offending array, and can track it down from there. Also, just so that I'm sure, are you using an old cscope.out file? If so, does this happen if you build the array index from scratch? That may explain why I'm not yet able to reproduce.
I updated my cscope.out file using make cscope after the last update of the kernel tree, which was yesterday evening.
ok, its NUMLEN that's too small. char linenum[NUMLEN + 1]; /* line number */ Setting NUMLEN to even be 200 stops the smash.
Created attachment 310032 [details] new patch to sanity check line numbers Hmm, ok. Well, NUMLEN is 5 digits, which should be enough to index a file that 99,999 lines long. I'm guessing that the kernel doesn't have any files that are 100,000 lines long, so I'm guessing that theres something wrong with the formatting of the cscope file, or that we're just parsing a file that is too large. I suppose it won't hurt anything to bump up that size by 1, which should let you index a million line file. I've also added a sanity check to cause a warning to be spit out if you index a file greater that what we have compiled support for. Please give this a go and let me know the results. Thanks!
So you forgot to bump up the size, and it crashed again, and I did not find anything in stderr. So I got about going on increasing the size to find the minimum that will help. At NUMLEN = 8 I got a new trace. Here it is Searching*** stack smashing detected ***: /usr/bin/cscope terminated Program received signal SIGSEGV, Segmentation fault. uw_frame_state_for (context=0xbfeb0794, fs=0xbfeb06d4) at ../../gcc/config/i386/linux-unwind.h:129 129 if (*(unsigned short *)(pc+0) == 0xb858 (gdb) bt #0 uw_frame_state_for (context=0xbfeb0794, fs=0xbfeb06d4) at ../../gcc/config/i386/linux-unwind.h:129 #1 0x00209702 in _Unwind_Backtrace (trace=0xa84dd0 <backtrace_helper>, trace_argument=0xbfeb0830) at ../../gcc/unwind.inc:294 #2 0x00a84fa8 in __backtrace (array=0xbfeb0d40, size=64) at ../sysdeps/i386/backtrace.c:122 #3 0x009ffa01 in __libc_message (do_abort=2, fmt=0xac7833 "*** %s ***: %s terminated\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:150 #4 0x00a87b58 in __fortify_fail (msg=0xac781b "stack smashing detected") at fortify_fail.c:32 #5 0x00a87b10 in __stack_chk_fail () at stack_chk_fail.c:29 #6 0x08054fe8 in search () at display.c:536 #7 0x080502ed in command (commandc=0) at command.c:531 Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb)
WE discussed this over IRC for most of yesterday, and based on our testing, this appears to be caused by the make cscope target of the kernel git tree including asm files in its file list. I'll submit a patch to the kernel to correct that. In the course of looking into this though, We did discover that rawhide cscope has a problem in which inverted indicies cause some problems resulting in invalid file format errors. I'll use this bug to track that down.
Or the fact that the function I was searching for had function pointers in its arguments, which too could have caused the stack corruption.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.