pjh@mccc.UUCP (Peter J. Holsberg) (12/01/87)
I wrote and compiled a large program and when it executes, I get a core
dump. (SysVr3 on a 3B2/400) When I try to use sdb, it refers me to a
nonexistent 'strncmp.c' file, and says:
0x80802d0b in strncpy:No lines in file
*Memory Fault (11) (sig 11)
at
0x80802d0b in strncpy:No lines in file
strncpy() is used many many times in the program, and is used
correctly, and with the proper header file.
What could be wrong???
--
Peter Holsberg UUCP: {rutgers!}princeton!mccc!pjh
Technology Division CompuServe: 70240,334
Mercer College GEnie: PJHOLSBERG
Trenton, NJ 08690 Voice: 1-609-586-4800peter@thirdi.UUCP (Peter Rowell) (12/02/87)
I suspect (but have no 3b2 to verify on) that one or more of the files
that make up your /lib/libc.a (which contains all of the standard C
library routines) were compiled with the "-g" switch. When sdb sees
this extra info, it wants to find the named file and display it.
It would seem that there is a bug in sdb (probably not the first you
have seen, and certainly not the last you will see) where they are not
catching that the file is not viewable. You could test for this by
creating a file called "strncmp.c" with a bunch of random lines in it
(at least as many as the original source file had) and then fire sdb up
again and see what it does. If it stops blowing up, that's the problem.
Fixing it will require removing "local symbols" from the library
without completely stripping it. This can be done by doing the
following:
#-------------------------
mkdir /tmp/newlib
cd /tmp/newlib
# get list of .o order in libc
ar -t /lib/libc.a > list
# extract the .o's
ar -x /lib/libc.a
# now we loop through and clean up unwanted symbols
for $file in `cat list`
ld -x -r $file
mv a.out $file
done
# finally we rebuild the library
ar -qv libc.a `cat list`
# and put it somewhere safe
mv libc.a /your/home/dir/or/what/ever
#-------------------------
Now you can reload using your new library and see if the problem goes
away. If it does, save your current /lib/libc.a somewhere and replace
it with your new libc.a.
There is one CAVEAT here: not all implementations of "ld" under
System V implement (or implement correctly) the "-x" switch. Your
version may do nothing, core dump, or do the correct thing....
Good Luck,
Peter Rowell
(415) 321-0967carroll@snail.CS.UIUC.EDU (12/04/87)
I means that the library function "strncmp" had a core dump, and sdb is looking for source to it. Obviously, there isn't any. What you should do is use the "t" command to trace back on the stack, and see what values you passed strncmp. It doesn't do any checking about the pointer values it gets (because that would be a real nightmare to implement, if not outright impossible). If you pass strncmp a bogus pointer, it will go ahead and try to use it, and then core dump, giving the effect you seem to have.
manes@dasys1.UUCP (12/04/87)
In article <161@mccc.UUCP> pjh@mccc.UUCP (Peter J. Holsberg) writes: > >I wrote and compiled a large program and when it executes, I get a core >dump. (SysVr3 on a 3B2/400) When I try to use sdb, it refers me to a >nonexistent 'strncmp.c' file, and says: > > 0x80802d0b in strncpy:No lines in file > *Memory Fault (11) (sig 11) > at > 0x80802d0b in strncpy:No lines in file > >What could be wrong??? Don't forget that C libraries also reference themselves and that a core dump on something like 'strncpy' or 'strcmp' may not be one that you put in your source file but called from something like printf(). The only thing you can really do is single-step through your code until the program dumps and see what library function caused the problem (after acertaining that your code is beyond criticism :^) Then check your arguments VERY closely and make sure that the function is getting all the arguments that it expects and of the proper type. Since you're getting a segmentation violation (sig 11) also check to make sure that you're linking withthe correct model (the linker SHOULD catch this). This wouldn't be Microport V/386 you're using, would it? -- +----------------------------------------------------------------------- + Steve Manes Roxy Recorders, Inc. NYC + decvax!philabs!cmcl2!hombre!magpie!manes Magpie BBS: 212-420-0527 + uunet!iuvax!bsu-cs!zoo-hq!magpie!manes 300/1200/2400
lvc@tut.UUCP (12/04/87)
In article <271@thirdi.UUCP>, peter@thirdi.UUCP (Peter Rowell) writes: > I suspect (but have no 3b2 to verify on) that one or more of the files > that make up your /lib/libc.a (which contains all of the standard C > library routines) were compiled with the "-g" switch. When sdb sees > this extra info, it wants to find the named file and display it. > ... Good guess, but actually, the 3b2 3b5 and 3b15 compilers insert this assembly language instruction: .file "filename" at the beginning of the .s file when you compile a file (with or without the -g option). This is where sdb is getting the file names. The assembler stores this and some other stuff in the a.out header. Which reminds me of a gripe I have with the 3b compilers, they also insert the time the program was compiled into the a.out header. I have to have a special program to compare two a.out files to see if they are the same! -- Larry Cipriani AT&T Network Systems at cbosgd!osu-cis!tut!lvc Ohio State University
randy@umn-cs.UUCP (12/05/87)
In article <2143@dasys1.UUCP> manes@dasys1.UUCP (Steve Manes) writes: >In article <161@mccc.UUCP> pjh@mccc.UUCP (Peter J. Holsberg) writes: [about a program that dumps core in a non-existant file strncpy.c] >> >>What could be wrong??? > >Don't forget that C libraries also reference themselves and that a core >dump on something like 'strncpy' or 'strcmp' may not be one that you put in >your source file but called from something like printf(). I haven't yet seen anyone mention the obvious solution: There's a call to the library strncpy routine in his program, and he's passing it a NULL (or other invalid pointer). Here's a question: why don't they put absolute path names in library modules? It wouldn't be any worse than the current situation, and in many cases (sites with source liscense, who use it) it would be reall handy. -randy -- Randy Orrison, University of Minnesota School of Mathematics | May the smiley UUCP: {ihnp4, seismo!rutgers, sun}!umn-cs!randy | O__\, ARPA: randy@ux.acss.umn.edu BITNET: randy@umnacca | O /' Disclaimer: No one is silly enough to pay me to do this. | be with you!