Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 452469 - cscope invalid file format errors when using inverted indicies
Summary: cscope invalid file format errors when using inverted indicies
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: cscope
Version: 8
Hardware: i386
OS: Linux
low
medium
Target Milestone: ---
Assignee: Neil Horman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-23 07:52 UTC by Dhaval Giani
Modified: 2009-01-09 07:50 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-01-09 07:50:26 UTC


Attachments (Terms of Use)
patch to truncate paths at max length (deleted)
2008-06-23 11:45 UTC, Neil Horman
no flags Details | Diff
new patch to sanity check line numbers (deleted)
2008-06-23 14:33 UTC, Neil Horman
no flags Details

Description Dhaval Giani 2008-06-23 07:52:13 UTC
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:

Comment 1 Neil Horman 2008-06-23 11:45:39 UTC
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!

Comment 2 Dhaval Giani 2008-06-23 12:20:23 UTC
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

Comment 3 Dhaval Giani 2008-06-23 12:49:54 UTC
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) 


Comment 4 Neil Horman 2008-06-23 13:16:27 UTC
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. 

Comment 5 Dhaval Giani 2008-06-23 13:23:35 UTC
I updated my cscope.out file using make cscope after the last update of the
kernel tree, which was yesterday evening.

Comment 6 Dhaval Giani 2008-06-23 13:37:35 UTC
ok, its NUMLEN that's too small.

char    linenum[NUMLEN + 1];    /* line number */

Setting NUMLEN to even be 200 stops the smash.


Comment 7 Neil Horman 2008-06-23 14:33:07 UTC
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!

Comment 8 Dhaval Giani 2008-06-23 15:22:35 UTC
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) 



Comment 9 Neil Horman 2008-06-24 11:03:06 UTC
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.

Comment 10 Dhaval Giani 2008-06-24 16:38:09 UTC
Or the fact that the function I was searching for had function pointers in its
arguments, which too could have caused the stack corruption.

Comment 11 Bug Zapper 2008-11-26 10:54:40 UTC
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

Comment 12 Bug Zapper 2009-01-09 07:50:26 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.